You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello, I'm investigating an unexpected com.apple.macl extended attribute while preparing a macOS application for Developer ID signing. I have observed the attribute in two places: On the root of an application bundle, where the recorded 72-byte attribute value changed during testing. On a Developer ID provisioning profile, where a 72-byte com.apple.macl value is present before signing. I also created a minimal Xcode reproducer that independently demonstrated the unexpected attribute behavior. I have not established which process creates or modifies the attribute, or whether its presence affects code-signing integrity. My questions are: Is this expected macOS behavior for app bundles and provisioning profiles? What is the recommended supported method to identify which system component creates or modifies this attribute? How should developers handle this situation when preparing and validating Developer ID signed applications? I would prefer to understand the cause rather than remove or suppress the attribute without knowing its security implications. Thank you.

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Updating an App for the first time since 2011. Build, Analyze, Archive all successful. Automatically Manage Signing checked. Validation fails with 90286 - Invalid code signing entitlements, and 91130 - Invalid Provisioning Profile dozens of times after tweaks, clean builds, trying manual signing (thought I was done with that), etc. For 90286 it seems my Developer ID , e.g. 346JXXXXX (not Team ID, QZ99XXXXX) is the prefix for the bundle ID, com.company.app-name and that generates the error? For 91130 it's invalid "com.apple.application-identifier" which I assume is the same issue with a Developer ID instead of a Team ID. The original version of the app was QZ99XXXXX.com.company.app-name. I even changed the bundle identifier in Xcode to that, and got this: App Record Creation failed due to request containing an attribute already in use. The app name you entered is already being used for another app in your account. If you would like to use the name for this app you will need to submit an update to your other app to change the name, or remove it from App Store Connect. Yes, the original app name is being used for an app in my account. I was trying to update the app, checked all the boxes, added update text, but of course there was no build to upload. Would appreciate any help.

I build a Chromium-based web browser for macOS. It's signed with Developer ID, notarized and distributed outside the Mac App Store. On 27 October I requested the managed capability Web Browser Public Key Credential Requests (com.apple.developer.web-browser.public-key-credential) for my App ID. On the App ID's Capability Requests tab it still shows "Submitted", with no email since. I need it for iCloud Keychain passkeys, and so that Apple's iCloud Passwords browser extension can start its helper. Users are reporting that the extension doesn't work. Request ID: H543AX456N Developer Support case: 30000006313896 (they're administrative and suggested I ask here) My questions: is there anything else I should send for this review, and is there somewhere to follow up on a pending capability request? And once it's approved, will the capability be included in a Developer ID provisioning profile, or only in Mac App Store profiles? Thanks!

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

Hi everyone, I'm trying to publish my first iOS app (a game built with the Godot engine), but every upload to App Store Connect fails with this error: "Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path "sevenatseven.app/sevenatseven" is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate." Setup: Xcode 27.1 (27A9275), macOS 27.0.1 The Xcode project is exported from Godot 4.7.2 (stable) Automatic signing with my paid team; no signing errors shown in Xcode Release configuration, Code Sign Identity: Apple Development (Xcode re-signs for distribution on upload) My account has a valid Distribution Managed certificate What I tried: Archive with "Any iOS Device (arm64)", then Distribute App > App Store Connect > Upload Clean Build Folder, fresh project export, new archive The archive always succeeds and the app runs fine on a real iPhone, but the upload is rejected every time with the same error on the main executable. What can cause this error on the main executable when the archive and signing look correct in Xcode? Is there a way to see which code requirement is failing, or a codesign command I should run on the archive to check it? Thanks!

Application Group identifier unavailable after moving from a Personal Team to a paid Apple Developer Program enrollment Hi everyone, I built an app in Xcode using a Personal Team (free, signed in with my Apple ID) with the bundle identifier com.jcsnp.Minutely. My paid Apple Developer Program enrollment has been active since 5 Nov 2026, and I'm now trying to build and run the app under the new team. Xcode is blocking me on the App Group and the provisioning profile. Environment macOS 27, Xcode 27.2, iOS target 26.6 Paid enrollment: individual account, active since 5 Nov 2026 Errors Communication with Apple failed. An Application Group with Identifier 'group.com.jcsnp.Minutely' is not available. Please enter a different string. No profiles for 'com.jcsnp.Minutely' were found Xcode couldn't find any iOS App Development provisioning profiles matching 'com.jcsnp.Minutely'. What I've tried Cleaning the build folder. The errors remain. Questions The App Group group.com.jcsnp.Minutely is reported as unavailable. Is it still registered to my old Personal Team, or to another account? If so, how do I release it or move it to the new team? Does the Personal Team's registration of the bundle ID need to be removed before com.jcsnp.Minutely can be registered under the paid team? Is there a recommended order for setting this up: registering the App ID and App Group in the developer portal first, then letting Xcode generate the profile? Thanks in advance for any guidance.

I'm testing Apple's official "Capturing screen content on iOS" sample architecture using Xcode 27.2 and a physical iPhone running iOS 27.2. My application builds, signs and launches successfully using a Personal Team without the screen-recording entitlement. However, when I add the entitlement required by Apple's sample, automatic provisioning fails with: "Entitlement com.apple.developer.screen-recording not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file." The generated provisioning profile does not contain the entitlement. Could Apple clarify: Is this entitlement available to Personal Teams for development? Does it require Apple Developer Program membership or separate capability approval? What is the supported procedure for obtaining a provisioning profile that includes it? Is there a known issue with entitlement availability or the iOS 27 sample? Our intended use is explicitly authorised full-display capture using the system picker, with on-device processing and no attempt to bypass user consent. I would appreciate guidance on the correct supported provisioning procedure.

We are looking for a supported way to establish an independent byte-level reference for two Apple-supplied executables: /bin/df and /usr/bin/codesign. This is a provenance inquiry, not an allegation of tampering or a known Apple defect. The Apple Developer OS download catalog lists macOS 27.0.1, build 26A434, released September 28, 2026, and links to this Apple silicon restore image: https://updates.cdn-apple.com/2026FallFCS/59241290-5d51-4ca8-9df4-31624b9a4eac/UniversalMac_27.0.1_26A434_Restore.ipsw We have saved whole-file lengths and SHA-256 observations from earlier local reads. Different observations had different whole-file digests. A separate historical OS version record identifies 26A434, but it is not contemporaneous with every file observation, so we use this build only as a candidate reference, not as an established build for every sample. The historical device context is Apple silicon / Mac18,5. No new machine inspection is requested or implied here. Questions: Does Apple publish, or have a supported way to obtain, authenticated whole-file byte lengths and SHA-256 values for these exact two paths in the 26A434 Apple silicon distribution? Please specify the applicable architecture and file representation. If not, is there a supported read-only procedure to authenticate the exact restore asset and extract these two complete files as a comparable reference, without installing or restoring macOS? What checks establish the build, model applicability and integrity of the extracted content? Are there documented transformations during installation, personalization or architecture selection that could make a valid installed file differ byte-for-byte from the corresponding restore-image file? If so, what comparison is supported without silently changing a whole-file-equality requirement? We understand from TN2206 and TN3126 that architectures in universal binaries are signed independently and that removing an architecture can preserve signature validity. A valid signature or CDHash is therefore not being treated as a substitute for our whole-file SHA-256 observations. Likewise, a checksum for the complete IPSW would not itself be the checksum of either executable. The intended comparison must not rely solely on the previously observed local codesign executable whose own whole-file binding changed. We are seeking a supported independent reference or verification method; we are not asking to disable Gatekeeper, SIP, authenticated-root protection, modify trust settings, re-sign system executables, or infer the cause of the historical differences. No system image has been downloaded or mounted for this inquiry. No passwords, account identifiers, keychain contents, private keys, logs, or attachments are included. References: https://developer.apple.com/download/os/ https://developer.apple.com/library/archive/technotes/tn2206/ https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web

Two notarization submissions for a Developer ID–signed macOS app have been "In Progress" for over an hour. Earlier submissions from this same team, credentials and workflow were all Accepted within minutes. Submissions Created (UTC)IDFileStatus2026-11-05 15:54:4802956de4-0ec7-4009-8f8e-1635f93a10d1ProxyPal.zipIn Progress2026-11-05 16:37:25e38d47a1-6709-4008-9682-18f9b96af217ProxyPal.zipIn ProgressThe second one is a resubmission of the identical zip, sent after the first had been stuck for about 40 minutes. What I've checked xcrun notarytool info <id> returns In Progress. xcrun notarytool log <id> returns "Submission log is not yet available". Authentication and upload work, and notarytool history lists both submissions. codesign --verify --deep --strict passes on the app. Every executable in the bundle has the hardened runtime and a secure timestamp. The zip is made with ditto -c -k --keepParent, the same command as the earlier accepted releases. The bundle contents are essentially unchanged since the last accepted release. The differences are a small generated static HTML help folder and version-number changes. Environment Submitted with xcrun notarytool submit ... --keychain-profile ... --wait from a script. macOS 26 (Darwin 25.6), Xcode toolchain notarytool. Zip is 89 MB, 193 files, and includes two nested .apk files that were also in earlier accepted releases. Questions Are these two submissions held for additional analysis, or stuck in the queue? Is there anything on my side I should change?

I've been unable to notarize an installer for an app (https://fxfactory.com/info/fxcore/) ever since adding a plug-in SDK that I was hoping to distribute as follows: /Library/Developer/SDKs/FxCore.sdk /Library/Developer/Xcode/Templates/FxCore/FxCore.xctemplate This creates the smoothest possible UX for someone who starts using the SDK, mimicking official SDKs. This is causing notarization failure, without a useful explanation, but a search suggests that Apple is preventing installers from touching the /Library/Developer directory as this might otherwise compromise the developer toolchain. What is the correct strategy for third-party SDKs? I'm assuming that ADDITIONAL_SDKS doesnt' care if the SDK isn't located at that specific location, but is there any other place where I can put the xctemplate and have it appear when creating a new project in Xcode? (I haven't tried using a post-install script to copy files after the fact but I’d assume that would fail... otherwise what would be the point of this extra safety check.) Thank you!

My first app cannot be uploaded: every IPA is rejected with ITMS-90035 "Invalid Signature". Setup: individual account, Team ID V7F74UFRBN, Xcode 27.0, macOS 26.6.2, Cloud Managed Apple Distribution certificate. My team name contains the Turkish letter "İ" (TELLİ). The certificate common name stores it as NFC (C4 B0), but the designated requirement written at signing time stores it as NFD (49 CC 87): certificate leaf[subject.CN] = 0x...54454c4c49cc87... so "codesign --verify --deep --strict" reports "does not satisfy its designated Requirement" for the app and every embedded framework. This looks like FB24633162 / thread 843700. I asked Developer Support to change my team name to the ASCII form "Mehmet Kaan TELLI" (case 103017162953) but have had no reply after several days, and the phone option shows as unavailable. Questions: Can DTS help escalate the team name change? Until then, is there a supported way to sign so the upload passes?

Title: Supported launch code requirement with direct posix_spawn and exclusive child reaping on macOS I'm designing a security-sensitive process-lifecycle controller on Apple silicon macOS. The controller directly launches a signed foreground executable and must satisfy two requirements: Before any child executable code runs, macOS must enforce a launcher-supplied requirement binding the child to approved code, preferably using LaunchCodeRequirement and CodeDirectoryHash. The original parent must retain exclusive ownership of the child's terminal status through waitpid(), with signalling and reaping serialised by one designated execution context. I understand that Foundation Process.launchRequirement supports launch-time executable constraints, whereas the established lifecycle currently uses direct posix_spawn(). Could Apple DTS clarify: 1. Is there a supported public API for supplying an equivalent launcher-owned code requirement through direct posix_spawn() or its attributes? 2. If Foundation Process is the supported route, can its caller exclusively consume the direct child's terminal status with waitpid() without competing automatic reaping or status consumption by Foundation? Or must callers use Foundation's own termination reporting? 3. If those requirements cannot be combined through one supported interface, is there a recommended public API or launch topology providing both pre-execution code-requirement enforcement and an attributable terminal-status oracle? I'm seeking supported contractual behaviour, not private implementation details. This question concerns executable identity and child lifecycle ownership only. It does not assume that process termination establishes containment of descendants, delegated work or pending external operations. Thank you.

Can someone tell me the applications requirements for using the secure enclave on MacOS? Does the application need to be signed with the secure-enclave entitlement in order to use it? Since this is a restricted entitlement, does my App ID need approval to use it from Apple? Currently I'm building in XCode 16 on Sequoia (15.5) using developer signing. My application is a C/C++ daemon running as plist out of /Library/LaunchDaemons. I have also built it as an application using the instructions here but this has not lead to a solution: https://developer.apple.com/documentation/xcode/signing-a-daemon-with-a-restricted-entitlement/ When I run my application from the command line via sudo signed but without the secure-enclave entitlement enabled in my entitlements file it runs. The first call to: SecAccessControlRef access = SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAccessControlPrivateKeyUsage, &error); succeeds without error. The call to create the key using: SecKeyRef privateKey = SecKeyCreateRandomKey(attributes, &error); then fails with error: (OSStatus error -50 - Failed to generate keypair) Here are the setup attributes (keySize = 256): CFDictionarySetValue(attributes, kSecAttrKeyType, kSecAttrKeyTypeECSECPrimeRandom); CFDictionarySetValue(attributes, kSecAttrKeySizeInBits, keySize); CFDictionarySetValue(attributes, kSecAttrLabel, keyName); CFDictionarySetValue(attributes, kSecAttrApplicationTag, keyLabel); CFDictionarySetValue(attributes, kSecAttrTokenID, kSecAttrTokenIDSecureEnclave); // Store in the Secure Enclave CFDictionarySetValue(attributes, kSecAttrKeyClass, kSecAttrKeyClassPrivate); CFDictionarySetValue(attributes, kSecAttrAccessControl, access); CFDictionarySetValue(attributes, kSecAttrIsPermanent, kCFBooleanTrue); // persist key across app restarts and reboots CFDictionarySetValue(attributes, kSecAttrCanEncrypt, kCFBooleanTrue); CFDictionarySetValue(attributes, kSecAttrCanDecrypt, kCFBooleanTrue); CFDictionarySetValue(attributes, kSecAttrAccessible, kSecAttrAccessibleWhenUnlockedThisDeviceOnly); CFDictionarySetValue(attributes, kSecReturnPersistentRef, kCFBooleanTrue); When I run the application signed and include the "com.apple.developer.secure-enclave" in my entitlements file it crashes at startup. I believe this is to be expected based on above. How do I proceed such that my application can use the secure enclave correctly?

I release my app both in the MAS and on my website. I use the same signing credentials, but necessarily different certs (Apple Development vs. Developer ID). When I run the MAS app and then run the other version, or vice versa, I need to re-authenticate the many privacy permissions each time (Finder AppleScript, Network browse, Full Disk Access), which is tedious and keeps causing trouble for other users because some of these require a tcc reset (which my app currently invokes manually, which I consider a hack, though). So, am I doing something wrong or is it really no possible to have both signed apps use the same identity with TCC?

An existing development-signed arm64 iPad Release build succeeds in Xcode, including its code-signing step. Post-build static verification from a restricted automation environment reports CSSMERR_TP_NOT_TRUSTED for Runner, App.framework, and Flutter.framework. The recorded commands were: codesign --verify --deep --strict --verbose=6 <app-path> codesign --display --entitlements - --xml <app-path> The entitlements command returns no XML and reports: binary contains an invalid entitlements blob; OS will ignore these entitlements This warning occurs only for Runner. The two frameworks have no entitlements slots. A public Security framework code-signing trust evaluation returned false, TrustResultValue 0, and an empty detailed result. The error and last underlying error were NSOSStatusErrorDomain / -26276, with description "OSStatus -26276". Existing observations: The Apple Development signing certificate matches the provisioning profile, which includes the target iPad. Keychain Access showed valid certificates using system-default trust. Offline code-page/resource hash and CMS signature checks matched. Offline parsing found matching XML/DER entitlement values within the profile's allowed values. These checks do not establish native trust or installation validity. The host is an Apple Silicon Mac and the target is a physical iPad. We have not isolated a focused Xcode sample that reproduces this issue. The original app contains Flutter and other integrations. We do not know whether the cause is in the artifact, trust evaluation, or the restricted execution environment. An OS log query was denied by that environment; it has not been retried or bypassed. We have not changed certificate trust, re-signed, rebuilt, or attempted installation to work around the verification failure. What supported, narrowly scoped diagnostic procedure would: distinguish a genuine trust-policy rejection from an evaluation that could not complete, diagnose the Runner-only entitlements warning, and establish whether the unchanged artifact is installable? Please advise the minimum redacted evidence or focused sample needed. We are seeking Apple's supported diagnostic route without exporting credentials or weakening trust settings. Attachments: none.

Since upgrading my free Apple Developer account to the paid Apple Developer Program (Individual) on September 21, 2026, every app signed with my paid team fails to install on my devices. TestFlight builds work. Error (Xcode Run, devicectl, Ad Hoc export): MIInstallerErrorDomain Code 13 / 0xe8008018 "The identity used to sign the executable is no longer valid." +[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:] LibMISErrorNumber = -402620392 What I've established: A brand-new Hello World app with no capabilities fails the same way, so it is not my project, entitlements or widget. The same Hello World signed by a free Personal Team installs on the same iPad (after trusting the developer in Settings). So the device, OS, Xcode and Mac are fine. Fails on iPad Pro 13" M4 (iPadOS 27.0.1 and 27.2), iPhone Air (iOS 27.0.1) and iPhone 15 Pro Max (iOS 26.0.1), with Xcode 27.0, 27.1 and 27.2. Fails with Apple Development signing (Xcode Run) and with an Ad Hoc export signed with an Apple Distribution certificate. codesign verifies the app, the embedded profile contains the signing certificate and the device UDIDs, and the chain (WWDR G3 to Apple Root CA) is valid and not expired. Regenerated the Development and Distribution certificates, cleaned expired WWDR certificates from the keychain, removed profiles on the device, re-paired and toggled Developer Mode. No change. Only apps re-signed by Apple (TestFlight) install. This looks like stale signing state for the team on Apple's side after the free-to-paid conversion. I have an open request with Apple Developer Support (Case-ID 22506476) and Feedback Assistant report FB24912726, but have had no reply in two weeks. Has anyone seen 0xe8008018 on a team that was recently upgraded or converted, and is there anything I can do on my side beyond asking Apple to reset the team's signing identity?

Hello Apple Developer Support, We are seeking clarification regarding the impact of the upcoming certificate changes taking effect on February 1, 2027. Our organization has previously distributed macOS installer packages (.pkg) that were: • Signed using a Developer ID Installer certificate that chains to the Developer ID Certification Authority intermediate certificate expiring on February 1, 2027. • Successfully notarized by Apple. • Signed with a secure timestamp. We are specifically seeking clarification on the impact of the Developer ID Certification Authority intermediate CA expiration on packages that were signed, securely timestamped, and successfully notarized prior to the expiration date. We would like to understand how these existing packages will be treated after February 1, 2027. Questions Will installer packages (.pkg) that were already signed, timestamped, and notarized before February 1, 2027 continue to install successfully after that date? Does notarization combined with a secure timestamp allow these previously distributed packages to remain trusted and installable after the certificate changes take effect? Are software vendors required to re-sign and re-notarize installer packages that have already been distributed if they were signed using certificates affected by this change? If re-signing is required, does this apply to: • Only new packages created after February 1, 2027, or • Existing packages that were previously notarized and distributed? Are there any recommended validation steps to determine whether an existing notarized package will continue to install successfully after February 1, 2027? Business Impact We are evaluating whether previously released installer packages signed with Developer ID Installer certificates that chain to the expiring Developer ID Certification Authority intermediate CA will remain deployable for customers after February 1, 2027, and whether any re-signing or re-notarization effort is required for our existing catalog of notarized installers. Without clarification, we cannot determine whether archived installers will continue to function as expected or whether remediation work is required to preserve the installability of previously released software versions. Thank you for your guidance. We would appreciate any relevant documentation or recommendations regarding best practices for existing notarized installer packages.

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue. All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating. I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago: error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>" ), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null)