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"

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.

I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.

I have been trying for 24 hours to upload app, and first time this has happened in 8 years and 100+ uploads. Please help. Validate App and Upload both hang indefinitely at "Preparing" in Xcode Organizer. No error is ever returned — the progress bar freezes and the operation never completes or times out. Transporter 1.4.5 fails identically. Key detail: archive 2.4.3 (build 123), which Apple accepted and processed on Sept 10, 2026, now hangs the same way when validated. Same machine, same Xcode, same Apple ID. This rules out the archive, its signature, and its provisioning profile. Already ruled out: two independent networks (home Wi-Fi and iPhone cellular hotspot); the archive itself (known-good build 123 fails identically); Xcode install (27.0 / 27A266a, xcode-select verified correct); Apple ID session (signed out and back in three times); full reboot. macOS 27.0 (26A428) on MacBookPro18,4. Last successful upload Sept 10, 2026. 100+ prior archives uploaded without incident over several years. macOS has updated twice since Sept 10. Separately: Transporter 1.4.5 crashes on macOS 27.0 with an unhandled exception in TransporterKit while drawing its activity queue (EXC_BREAKPOINT via +[NSApplication _crashOnException:]).

I created a new App project, I didn't write any my code, I just built it and install it to my iPhone, then I got the error as below: 无法安装“test” Domain: IXUserPresentableErrorDomain Code: 14 Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.X9zsVD/extracted/test.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Please ensure that the certificates used to sign your app have not expired. If this issue persists, please attach an IPA of your app when sending a report to Apple. User Info: { DVTErrorCreationDateKey = "2025-04-13 03:40:21 +0000"; IDERunOperationFailingWorker = IDEInstallCoreDeviceWorker; } -- Failed to install the app on the device. Domain: com.apple.dt.CoreDeviceError Code: 3002 User Info: { NSURL = "file:///Users/ltf/Library/Developer/Xcode/DerivedData/test-fnnhrmtlclvfdnennxoorbywbuze/Build/Products/Debug-iphoneos/test.app"; } -- Can't install “test” Domain: IXUserPresentableErrorDomain Code: 14 Failure Reason: 无法安装此App，因为无法验证其完整性。 Recovery Suggestion: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.X9zsVD/extracted/test.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) -- Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.X9zsVD/extracted/test.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) Domain: MIInstallerErrorDomain Code: 13 User Info: { FunctionName = "+[MICodeSigningVerifier _validateSignatureAndCopyInfoForURL:withOptions:error:]"; LegacyErrorString = ApplicationVerificationFailed; LibMISErrorNumber = "-402620392"; SourceFileLine = 79; } -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { "device_identifier" = "00008120-001E51C011F9A01E"; "device_isCoreDevice" = 1; "device_isWireless" = 1; "device_model" = "iPhone15,5"; "device_osBuild" = "18.3.2 (22D82)"; "device_platform" = "com.apple.platform.iphoneos"; "device_thinningType" = "iPhone15,5"; "dvt_coredevice_version" = "443.19"; "dvt_coresimulator_version" = "1010.10"; "dvt_mobiledevice_version" = "1784.120.2"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = arm64; "operation_duration_ms" = 2527; "operation_errorCode" = 14; "operation_errorDomain" = IXUserPresentableErrorDomain; "operation_errorWorker" = IDEInstallCoreDeviceWorker; "operation_name" = IDERunOperationWorkerGroup; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphoneos"; "param_diag_113575882_enable" = 0; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_guardMalloc_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_mtc_enable" = 1; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_enable" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 2; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 99; "param_launcher_substyle" = 0; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_structuredConsoleMode" = 1; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphoneos18.4"; "sdk_osVersion" = "18.4"; "sdk_variant" = iphoneos; } -- System Information macOS Version 15.5 (Build 24F5042g) Xcode 16.3 (23785) (Build 16E140) Timestamp: 2025-04-13T11:40:21+08:00

Summary A third-party PKG installer that ships a custom Installer Plugin no longer displays one of its selection panes. The plugin bundle appears not to be loaded, so the pane that it provides is silently skipped and the user cannot choose the intended installation option. This behavior started with recent macOS releases and did not occur on the immediately preceding versions, so it looks like a regression. Environment Machine: MacBook Pro 14-inch (M3) Affected builds: macOS 27.0 (26A428) macOS 26.7 (25G229) macOS 15.8 (24H23) Not affected: macOS 26.6 and earlier macOS 15.7 and earlier Reproducibility: every time Plugin binary: Mach-O 64-bit bundle, x86_64 only (no arm64 slice) Steps to Reproduce Download the Epson iProjection Ver.4.04 installer from the vendor support site: https://support.epson.net/setupnavi/?LG2=EN&OSC=MI&PINF=vpapp&MKN=EB-770Fi Mount the downloaded disk image and run the PKG installer. Step through the installer GUI and observe the pane transitions. Expected Result The installer GUI shows the "Application type" selection pane provided by the bundled Installer Plugin. Actual Result The "Application type" pane is never shown. The installer proceeds as if the plugin did not exist, and the user cannot select the installation type. What I Checked 1. The plugin is present inside the PKG pkgutil --expand-full PKG_PATH DEST_DIR The expanded payload contains the plugin bundle and its Mach-O executable under Contents/MacOS. 2. Architecture of the plugin binary file DEST_DIR/PluginName.bundle/Contents/MacOS/PluginName Result: Mach-O 64-bit bundle x86_64. It is a single-architecture binary with no arm64 slice. 3. The plugin is actually touched at install time sudo fs_usage -w -f filesys InstallerRemotePluginService-x86 opens the plugin executable inside the installer's temporary directory (a path under /private/tmp/com.apple.installer* ). So the plugin is reached as a load target, but the pane still does not appear. 4. Code signature validation When the installer is launched directly from the mounted disk image, code signature validation fails with: Too many levels of symbolic links My working theory is that the bundle contents are turned into symbolic links when the plugin is expanded, and that this causes codesign validation to fail, so the plugin is rejected before it can register its pane. 5. Code evaluation by syspolicyd log stream --info --debug --predicate 'process == "syspolicyd"' GK package assessment, GK process assessment and GK performScan entries are present, so Gatekeeper evaluation itself is running. The following also appears: Error Domain=NSOSStatusErrorDomain Code=-67062 Unsigned code in: PST: (path: REDACTED), (team: (null)), (id: (null)), (bundle_id: (null)) The PST path is anonymized in the log, so I could not confirm that this particular assessment refers to the plugin bundle. 6. XProtect evaluation results differ between versions log stream --info --debug --predicate 'process == "syspolicyd"' On the versions where the installer works correctly, the GK Xprotect results lines explicitly include a file URL pointing at the plugin bundle inside the installer temporary directory. On the affected builds, searching the same log for the plugin bundle name returns zero matches. That suggests the bundle is not being processed as an XProtect evaluation target at all on the newer builds. Question Was there a change in how Installer Plugins are expanded or validated in these releases, in particular around symlinked bundle contents or single-architecture x86_64 plugins? Any guidance on the supported way to ship an Installer Plugin so that it is still loaded on current macOS would be appreciated.

I have a follow-up question about file-based Keychain ACLs, this time specifically about inspecting the authorization state after it has been configured. I’ve been looking through the public SecAccess / SecACL / SecTrustedApplication APIs. I can enumerate ACL entries and their authorizations, and SecACLCopyContents gives me the trusted applications associated with an ACL. What I haven’t been able to establish is whether the complete stored caller-matching condition can be read back through a supported API. In particular, SecTrustedApplicationCopyData returns opaque application-identifying data. Is that data intended to be a complete representation of the condition that the Keychain will use to recognize that trusted application? Or can the stored trusted-application condition contain additional code-signing requirements or other matching constraints that are not represented by SecTrustedApplicationCopyData? My higher-level requirement is to verify, after configuring a private key, that its effective authorization scope is no broader than an independently reviewed policy. Ideally I would like to compare: the authorized private-key operations; all trusted-application subjects and their complete matching conditions; prompt-related state; and partition-list constraints. Is there a public and supported API, or an Apple-provided tool with a supported machine-readable contract, that can enumerate the complete effective authorization state of a private key in a file-based Keychain? I’m deliberately not trying to infer this from the current executable’s path, designated requirement, hash, security dump-keychain output, or representative negative tests unless Apple considers one of those to be the supported way to establish the stored authorization state. I realise from the existing guidance, including TN3137 and the discussion around file-based Keychains, that this is legacy technology. If complete supported introspection simply isn’t available for this model, knowing that limitation would also answer my question. Thanks.

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect. The exact same .pkg works on macOS 26.6, and per thread 842811 the same bundles were fine on 27 betas 1–4(I have tested it from beta 6 onwards). While investigating we found what looks like the underlying cause, and it's reproducible by hand. THE FINDING During a failing install, look inside the extracted plugin bundle while the Installer window is still open: ls -la /private/tmp/com.apple.installer*/.bundle/Contents/ That layout fails code-signature validation. You can reproduce the failure manually, no Installer involved: codesign -vvv "/private/tmp/com.apple.installer"*/.bundle → .bundle: Too many levels of symbolic links WHAT THE SYSTEM LOGS SHOW amfid rejects the plugin executable: /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/ not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" with repeated "UNIX error exception: 62" (errno 62 = ELOOP, too many levels of symbolic links) in backtraces through BundleDiskRep::component → SecStaticCode::component → validateNonResourceComponents → staticValidateCore, and "Code failed basic validity check (error: 100062)". For a Developer ID–signed plugin the kernel then treats it as fatal: AMFI: When validating /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/: The code contains a Team ID, but validating its signature failed. mac_vnode_check_signature: ... code signature validation failed fatally check_signature[pid: N]: error = 1 The plugin is never dlopen'd and the pane never appears. QUESTIONS Is there a way to get Installer to deploy the bundle with real files — or any other workaround? Note : I have Filed via Feedback Assistant as FB24601496; this overlaps FB24415432 / thread https://developer.apple.com/forums/thread/842811, which we've cross-referenced I have experienced this issue on latest Beta 8 build also -27.0 Beta (26A5425a)

I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. xcrun notarytool info no longer shows any meaningful state for them. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress (~2.5h): CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict → "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers + ~180 PyInstaller backend binaries) signed inside-out. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck looks like an account-level backend issue, not a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress: CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict returns "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers plus ~180 PyInstaller backend binaries) are signed inside-out These packages are essentially identical in size and structure to our previous release 2.1.7, which notarized within minutes. In fact 2.1.8 is about 1 MB smaller than 2.1.7 (arm64 dmg 214.2 MB vs 215.3 MB; x64 dmg 223.3 MB vs 224.5 MB), so this is not a large or unusual upload. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck, while the packages verify cleanly and match a previously-accepted release, looks like an account-level backend issue rather than a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Since our 1.3.20 update reached users on Sept 11, 2026, a handful of devices terminate at launch right after the App Store auto-update. Restarting the device does not help; deleting the app and reinstalling it from the App Store does. Filed as FB24755993 with 9 crash reports, the delivered package's SC_Info/Manifest.plist and a per-binary fingerprint. What the crash reports say (all identical) Exception Type: EXC_CRASH (SIGABRT) Termination: namespace DYLD, code 1, "Library missing" (terminated at launch; ignore backtrace) Library not loaded: @rpath/FBSDKCoreKit.framework/FBSDKCoreKit Referenced from: <DDB434B7-...> /Volumes/VOLUME/*/Runner.app/Runner Reason: tried: '/private/var/containers/Bundle/Application/<UUID>/Runner.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit' (could not register fairplay decryption, mremap_encrypted() => -1) Backtrace: dyld4::prepare -> dyld4::halt -> abort_with_payload Devices so far: iPhone XR / iOS 18.7.10 (22H374), iPhone 16 / iOS 26.6, iPhone 16 / iOS 18.7.7, plus one more not yet identified. The same package launches normally on the large majority of the ~12,000 devices that updated that day. Delivered Info.plist: DTAppStoreToolsBuild 27A261, DTXcodeBuild 17F113, MinimumOSVersion 15.0. What we established The main executable decrypts fine (dyld reaches dyld4::prepare); the failure is on the first @rpath framework in the load order, which is also the first FairPlay-encrypted embedded binary. It is not specific to the Facebook SDK. The package Apple delivers (pulled with Apple Configurator) is structurally consistent: every binary with LC_ENCRYPTION_INFO_64 has cryptid 1 and SC_Info/<name>.supp/.supf/.supx/.v4.supp/.v5.supf (main executable, App, Flutter, FBSDKCoreKit, FBAEMKit, FBSDKCoreKit_Basics, objective_c, sqlite3, the widget appex); the Firebase/Google frameworks are cryptid 0. SC_Info/Manifest.plist has SinfPaths = [SC_Info/Runner.sinf] and SinfReplicationPaths for all 12 binaries. Only the main Runner.sinf ships; the framework-level .sinf files have to be produced at install time from SinfReplicationPaths. The symptom looks like that replication not being applied to the frameworks after the delta update on the affected devices, while a fresh full install performs it. Nothing in our bundle changed between 1.3.19 and 1.3.20 except Dart code (App.framework): same Xcode 26.6 (17F113), same Flutter engine, byte-identical Facebook SDK 18.1.1 binaries (the only fat arm64+arm64e binaries in the bundle), same Firebase SDK. Both versions run normally from TestFlight and Xcode. The 1.3.20 encrypted variant carries SC_Info timestamps about 18 h after Ready for Sale, coinciding with the start of the auto-update wave. We could not obtain the delivered 1.3.19 package for comparison. Questions Has anyone seen this class of failure since early September, or with packages processed by DTAppStoreToolsBuild 27A261? Is there anything about a bundle (fat arm64+arm64e embedded frameworks? many encrypted frameworks?) that makes the framework .sinf replication on the delta-update path fragile? Is there any developer-side mitigation other than telling users to delete and reinstall? The closest earlier report I found is thread 718950 (2022, iOS 15.7–16.1, ~1 in 200 installs, "reinstall fixes it"); this looks like the same failure but concentrated on one update. fingerprint-1.3.20.json

I am new here. I am trying to do a build and run in Xcode. I keep getting a popup that says: code sign wants to access key "Apple Development: David Smith (David Smith" in your keychain. I have already granted access in keychain access, yet this popup persists. I have tried entering the keychain password and my Apple ID password; neither one works. How do I get around this?

Hello, I am very new to programming for iPhone, so please excuse me if this question is ignorant and I'm missing something silly. I am trying to build an app for my phone (iPhone SE 3rd gen) using my Macbook Air (same Apple Account). I downloaded XCode and started with the default "Hello World!" template. I created a personal team and figured out all the settings on my phone (trusted the computer, turned on developer mode, trusted the account). However, after uploading, I get the following error: The weird part is that I have a stable internet and cell connection. Following the instructions given to me in the similar error on my Mac, I head to General -> VPN and Devices -> my account and click "Verify App". This gives me a pop-up: Clicking Verify, it loads for a second and absolutely nothing happens. Not sure how to proceed or what's wrong.

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

I’m packaging a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. The ZIP uploads successfully, the manifest is accepted, and the Packager automatically creates the related Extension identifier. However, every build fails during export with: Exporting for App Store Distribution failed. Please download the logs artifact for more information. It also shows: Exporting for Development Distribution failed. Please download the logs artifact for more information. There is no Logs, Artifacts, or Download button on the build or issue page. To isolate the problem, I tested: Manifest V2 and Manifest V3 A minimal extension containing only HTML and icons No JavaScript, permissions, host permissions, APIs, or external dependencies A completely new App Store Connect app A new explicit Bundle ID A name-matched extension ZIP Multiple version and build numbers Every test produced exactly the same export errors. The App Store Connect agreement is active, and the Account Holder has access to cloud-managed distribution certificates. Because even a clean minimal extension and a newly created app fail identically, this appears to happen during cloud signing, provisioning, or archive export—not while parsing the extension. Questions: How can I download the logs artifact requested by the error when the Packager interface does not provide it? Can Apple confirm whether the web-based Packager currently has an export or automatic-signing issue? Is there any required certificate, provisioning profile, App ID configuration, or account permission that the Packager does not create automatically?

Hello, I am trying to use XCode to generate a 'embedded.provisionprofile' file. My Xcode macos project keeps giving me an error saying: Provisioning profile "BRandNewMebedded" doesn't include signing certificate "Apple Distribution: Martin Barker (LV6WXG529F)". When I download the Provisioning Profile file "BRandNewMebedded" from online, I make sure it has "Mac App Distribution" checked, but even if i edit it to use the first option "Distribution" and re-download it, my XCode keeps saying the same error in red.

Installing a development build on a physical iPhone fails with: 0xE8008018 - The identity used to sign the executable is no longer valid. On the same Mac, same iPhone, same codebase and same Xcode, switching to a free personal Apple ID team installs and runs with no error. Only builds signed with our paid organisation team fail. Nothing else changes between the two runs. We have already regenerated certificates and provisioning profiles, deleted the profiles folder, cleared DerivedData, removed old identities from the keychain, trusted the profile on device, and tried both automatic and manual signing. None of it changes the result. We have also gone through the existing threads on this error and none of the suggested fixes apply. The build validates locally but the device rejects the identity. Since the signing team is the only variable between success and failure, what should we be looking at? A support case is open with Developer Support but we have not had a technical response yet.

Hi Apple DTS and community, My developer account's app has been granted the Default Mail App managed capability (com.apple.developer.mail-client). The capability works for Development and App Store Connect distribution, but it is not enabled for Ad Hoc distribution. This prevents us from using our Xcode Cloud “Archive & TestFlight” workflow: The archive succeeds. Development and App Store Connect exports succeed. Xcode Cloud then automatically attempts an Ad Hoc export. The Ad Hoc export fails, causing the entire archive action to fail and the TestFlight post-action to be skipped. The export log reports: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We have reproduced this in two consecutive Xcode Cloud runs. We also confirmed that: The App ID has the Default Mail App capability enabled. The entitlement is present and correctly spelled in the app’s entitlements file. The App ID’s provisioning support lists Development and App Store Connect, but not Ad Hoc. Our Xcode Cloud workflow does not expose an option to disable the automatically attempted Ad Hoc export. This appears to match these previous reports: https://developer.apple.com/forums/thread/774506 — a DTS engineer enabled Ad Hoc support for the entitlement, after which the developer confirmed the issue was resolved. https://developer.apple.com/forums/thread/800072 — DTS confirmed that the Ad Hoc distribution option must be enabled for the Default Mail App managed capability. We also opened an Apple Developer Support case (102945477410). Developer Support directed us to the forums and indicated that this issue would need to be handled by DTS engineers. I can provide our Team ID, Developer Support case number, Xcode Cloud run identifiers, and any other account details privately if needed. Thank you!

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.