Hi, I currently have multiple notarization submissions that have been stuck in "In Progress" status for many hours without any updates. Here are several examples from my recent submissions: Submission IDs: 01f7a80e-a9cc-49b3-bb93-94b126cf3124 (a.dmg) 7af2b25f-e131-40a4-bcd3-0f7583ebbdc2 (a.dmg) 2b35ec79-d851-41d6-a900-788d4201a273 (b.dmg) 8194b1af-a270-4de9-92f1-ce2a8d4782f2 (c.dmg) 2608dcfc-7652-4efa-97e3-1749e7130dcb (d.zip) These submissions were created between March 11 and March 12, and all of them remain stuck in the "In Progress" state indefinitely. When checking using: xcrun notarytool history all recent submissions appear as: status: In Progress Additionally: No logs are available for these submissions. notarytool --wait eventually times out after 30 minutes with exit code 124. The app bundles are signed with a valid Developer ID Application certificate. All embedded frameworks and dylibs are individually signed using: --options runtime --timestamp Earlier submissions on the same day (for example df41010c-a3c6-4e2d-a455-b657693e8541) were successfully notarized and returned Accepted, so the signing configuration appears to be correct. Because many submissions across different files (DMG and ZIP) are stuck in the same state, it seems possible that the notarization service queue may be stalled. Could you please help confirm: Whether these notarization submissions are stuck on the Apple notarization service side If there is currently a service issue affecting notarization processing Whether I should cancel and resubmit these uploads Any guidance would be greatly appreciated. Thank you.

Hi support, Currently we are in a process of migrating our Qt application for MAC OS - ventura -v13.4. There is a specific feature in our application in which client tries to communicate with server (Socket communication) using Qt's QsslSocket Apis . To achieve this we are using self signed Ca certificate (.pem ) generated by using openSSl commands which uses IP address of the server. We are manually installing the certificate inside MAC OS - keychain and trusting it manually as well after installing . This is working fine in XCode environment in debug mode in MAC OS and client -server handshake is happening successfully. How ever after creating .dmg file (installer) the same handshake is not happening and we are getting error -Connection time out. Upon investigating this online, we got to know there has to be codesigning (both app bundle and the dmg file )along with notarization of the .dmg file in order to access keychain of MAC OS at runtime to access the self signed certificate installed. Now we have 2 queries here. Is code signing mandatory if we want to verify our app through keychain with .dmg file ? If yes, whats the best way to achieve this ? We have tried 2 options without any luck. option1 - Trying to build our specific target among 'ALL_BUILD' with signing key settings inside xcode where we are providing developer provisional certificate with apple team ID . After that we are trying to archive to generate dmg file which is code signed. We are failing here as the signed dmg is not getting installed due to other app related dependencies are missing . option 2- Code signing the dmg and the app bundle manually outside the environment of xcode with developer certificate and team ID. We are failing here as notarization needs to be done it seems to access keychain for certificate verification If Code signing is not mandatory then whats the best possible way to achieve this considering manually installation of certificate inside keychain with adding trust option is not working at the moment. Please specify the best solution if possible.

I'm working on an app that needs access to device activity. When I add device activity entitlement, I'm getting Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. This is failing for both, the main app and the extension, and both have entitlements added. It is not clear how to add it to the profile, the provisioning profile is created/managed by XCode. When I remove the entitlement, I can build my app but it won't be able to use device activity data I reached out to Developer Support, and they sent me here. What is the right way to add device activity entitlement? I'm also seeing another issue with XCode Cloud builds. When I remove device activity entitlement. I can build my app w/o any issue, and I can also install it directly on my iPhone. However, XCode Cloud builds fail wit Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/d41fc2f1-4f39-4906-8941-112488e75f6c.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.68.193:8089' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' I suspect that it could be related to my app having DeviceActivityExtension but no device activity entitlement is present. Thanks, Peter.

I have app developed in electron.js and python and it works in ios 15 after codesigning but not in ios 14 or below I need to understand if theres a specific instruction that we need to while building the app or do I need to codesign in lower version? what can I do solve this issue??

Validation failed (409) Missing Code Signing Entitlements. No entitlements found in bundle 'com.seeyon.yiboyun.child' for executable 'Payload/M3.app/PlugIns/CMPSharePublish.appex/CMPSharePublish'." (ID: 6e5429ed-b896-45a0-ab23-bb8fcb472072)

Hello all, I am attempting to notarize my newly made Mac OS application using the notarization command in VS Code. "/Users/teejgotit/Desktop/Cursor Workspace/Rust CutContour v2/cutcontour-app/src-tauri/target/release/bundle/dmg/CC Studio_0.1.0_aarch64.dmg" \ --key "/Users/teejgotit/AppleCerts/AuthKey_MATVLX3.p8" \ --key-id "MATVLX9" \ --issuer "887ba428-aa39-4fb3-a3dc-f83b9145cab0" \ --wait Only to be met with a continual "Current State: In Progress.." for what has been about 1 day and 16 hours now. Current status: In Progress........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ My app and project are rather small and was curious if this is a normal thing for this to day takes for a first time notarization? Would love any help or feedback.

I have added an in-app purchase function into my app, and have enabled in-app purchase profile in developer portal(it's on by default and is marked gray in developer portal, I don't know if that's how it supposed to look like). I have issued the agreements and tried signing the app both manually and automatically, but neither of that worked. App can be built successfully in simulator but does not show the simulation window, but cannot build on real device or archive. Errors: Missing com.apple.developer.in-app-purchase, com.apple.developer.in-app-purchase.non-consumable, and com.apple.developer.in-app-purchase.subscription entitlements. Automatic signing failed Xcode failed to provision this target.

The capability associated with "FAMILY_CONTROLS" could not be determined. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator.

Hello, we are currently encountering a similar issue. We need to inject our capabilities into a third-party app by re-signing it (not a full re-signing process—just requiring the provisioning profile and certificate to match). However, this seems to affect the functionality of universal links. We've found that this issue only occurs on iOS 18. We noticed that when re-signing the app, the entitlements related to associated domains are changed to a wildcard: [Key] com.apple.developer.associated-domains [Value] [Array] [String] * However, this doesn’t cause any issues on iOS 17. Through further testing, we discovered that in order for universal links to work properly, we need to restore the original value of com.apple.developer.associated-domains and use a provisioning profile that matches the app's bundle ID. This means our previous re-signing approach using a certificate and provisioning profile from another bundle will no longer work. We’d like to ask: is this a new restriction introduced in iOS 18? If we manually restore the original com.apple.developer.associated-domains entitlement and use a provisioning profile that matches the app’s bundle ID, will universal links function correctly going forward?

Can you please help us with the scenario below, including details and Apple’s recommendations? I've already read through the Notarization and Gatekeeper documentation. The installed version of our application is 1.2.3, located in /Applications/XYZSecurity.app. We created an upgrade package for version 1.2.4. As part of the pre-install script in the 1.2.4 installer, we explicitly deleted some obsolete .dylib files from /Applications/XYZSecurity.app/Contents/Frameworks and some executable files from /Applications/XYZSecurity.app/Contents/MacOS that were no longer needed in version 1.2.4. The installation of version 1.2.4 completed successfully, but we see the below error logs in installer.log: PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/Frameworks/libhelper.dylib PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/MacOS/helper-tool Our Key Questions: Is it the right practice to remove obsolete files in the pre-install script during an upgrade? Is this approach recommended by Apple? Can this cause any issues with Apple Gatekeeper? Is there a possibility of my application getting blocked by Gatekeeper as a result?

Hi, I have some doubts about certificates expiration given this "new" requirement around signing for some common third party SDKs: https://developer.apple.com/support/third-party-SDK-requirements/ Use case: I build an SDK that will be distributed as an XCFramework and will be used in AppStore apps from different people. My SDK internally uses some other third party libraries that are integrated as binaries Let's assume some of those third party libraries are from the list above and therefore seem to be required to be signed. I distribute my SDK with all in order (third party SDKs from that list with valid signatures) People using my SDK over the time provide an update to their apps on the AppStore but by then some of the third party libraries of my SDK has an expired certificate. What would happen? People using my SDK won't have any issues as far as my SDK has a valid signature (despite third party libraries from the list have expired signatures) People using my SDK will get a warning about it but still will be able to submit to the AppStore. In that case, would AppStore Review process decline the update? People using my SDK will get an error, not being able to submit to the AppStore and will require me an update version of the SDK with those third party libraries re-signed. My understanding is that all would work as far as my SDK has a valid signature (after all is the one taking responsibility of the code inside), independently of what happens with the signature of those libraries themselves, am I correct?.

IMPORTANT The underlying issue here (FB8830007) was fixed in macOS 11.3, so the advice in this post is irrelevant if you’re building on that release or later. Note This content is a repost of info from another thread because that thread is not world readable (it’s tied to the DTK programme). A number of folks have reported problems where: They have a product that supports older versions of macOS (anything prior to 10.11). If they build their product on Intel, everything works. If they build their product on Apple Silicon, it fails on those older versions of macOS. A developer filed a bug about this (FB8830007) and, based on the diagnosis of that bug, I have some info to share as to what’s going wrong and how you can prevent it. Let’s start with some background. macOS’s code signing architecture supports two different hash formats: sha1, the original hash format, which is now deprecated sha256, the new format, support for which was added in macOS 10.11 codesign should choose the signing format based on the deployment target: If your deployment target is 10.11 or later, you get sha256. If your deployment target is earlier, you get both sha1 and sha256. This problem crops up because, when building for both Intel and Apple Silicon, your deployment targets are different. You might set the deployment target to 10.9 but, on Apple Silicon, that’s raised to the minimum Apple Silicon system, 11.0. So, which deployment target does it choose? Well, the full answer to that is complex but the executive summary is that it chooses the deployment target of the current architecture, that is, Intel if you’re building on Intel and Apple Silicon if you’re building on Apple Silicon. For example: intel% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … intel% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha256 … arm% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha256 … The upshot is that you have problems if your deployment target is less than 10.11 and you sign on Apple Silicon. When you run on, say, macOS 10.10, the system looks for a sha1 hash, doesn’t find it, and complains. The workaround is to supply the --digest-algorithm=sha1,sha256, which overrides the hash choice logic in codesign and causes it to include both hashes: arm% codesign -s - --digest-algorithm=sha1,sha256 Test664892.app arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … % codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm distributing a macOS .pkg installer signed with Developer ID Installer and notarized via notarytool. On macOS 26.3 (Tahoe, Build 25D125), the package is rejected by Gatekeeper when downloaded from the internet. What works: pkgutil --check-signature → signed, Developer ID Installer, full chain (G2 intermediate + Apple Root CA) xcrun stapler validate → "The validate action worked!" xcrun notarytool info <id> → status: Accepted The .app inside the .pkg passes spctl -a -vvv → "accepted, source=Notarized Developer ID" What fails: spctl -a -vvv --type install mypackage.pkg → rejected, origin=Developer ID Installer Raw assessment: assessment:remote = true, assessment:verdict = false Double-clicking the downloaded .pkg shows only "Move to Trash" / "Done" (no "Open" option) syspolicyd log: meetsDeveloperIDLegacyAllowedPolicy = 0 (expected, since the cert is new), but no "notarized" match is logged Certificate details: Developer ID Installer, issued Feb 28, 2026, valid until 2031 OID 1.2.840.113635.100.6.1.14 (Developer ID Installer) — critical OID 1.2.840.113635.100.6.1.33 — timestamp 20260215000000Z Intermediate: Developer ID Certification Authority G2 (OID 1.2.840.113635.100.6.2.6) security verify-cert → certificate verification successful Build process: productbuild --distribution ... --sign <SHA1> (also tried productsign) Both produce: Warning: unable to build chain to self-signed root xcrun notarytool submit → Accepted xcrun stapler staple → worked Workaround: xattr -d com.apple.quarantine ~/Downloads/mypackage.pkg allows opening the installer. Question: Is spctl --type install assessment expected to work differently on macOS 26 Tahoe? The same signing and notarization workflow produces .app bundles that pass Gatekeeper, but .pkg installers are rejected. Is there a new requirement for .pkg distribution on macOS 26? Environment: macOS 26.3 (25D125), Xcode CLT 26.3

When I create an archive file and attempt to upload the app using the "Distribute App" button, the upload fails with the error "Automatic signing cannot update bundle identifier...". (The detailed message is below.) When creating an archive file in Xcode, I unchecked "Automatically Manage Signing" and proceeded with the archive. The message says "Font Enumeration," but other apps with the same option enabled upload successfully. Therefore, I believe the "Font Enumeration" option is not the issue. I tried creating a new provisioning file, but it still doesn't work. I deleted all DerivedData files from my Mac storage, restarted Xcode, and tried again, but it still doesn't work. This keeps happening only for certain targets (specific apps) in Xcode. Does anyone know how to fix this? Xcode is the latest version. Message: Automatic signing cannot update bundle identifier "com.xxxxxx.xxxxxx". Automatic signing cannot update your registered bundle identifier to enable Font Enumeration. Update your bundle identifier on https://developer.apple.com/account and then try again.

Greetings! I've notarized my app but it spends always over 1 hour. I think it's because the app size is about 30GB, but is there any way to reduce it?

Hey, So i am trying to setup OpenGL on my mac. Specs : M2 Pro, 15.5 (24F74) Now i have setup the entire project properly as far as i know. GLFW, GLAD and the OpenGL framework. the build libraries are also reference and everything. I have also included the glad.c file in the folder. i have also kept it to run locally in signing tab. its still giving me Command CodeSign failed with a nonzero exit code All the ss are provided

Hello, I had a successful attempt at notarization earlier today in my build pipeline. I've been using the same system for building my macOS application for over a year now. However, subsequent builds seemed to fail. I found a couple similar topics which makes this seem not not an isolated incident: https://developer.apple.com/forums/thread/782950 https://developer.apple.com/forums/thread/783347 https://developer.apple.com/forums/thread/783283 In my case I use the following command to submit the notarization: xcrun notarytool submit FilePath.dmg --apple-id "myappleid@gmail.com" --password "redacted_obviously" --team-id "my-team-id" --wait I left a previous run go for over an hour and the "Current status: In Progress.................. etc" filled the whole terminal. I manually checked the progress of the submissions using the command below: xcrun notarytool log --apple-id "myappleid@gmail.com" --password "redacted_obviously_again" --team-id "my-team-id" [run id] And they all result in the following output: Submission log is not yet available or submissionId does not exist Is anyone else experiencing this? Are there any possible solutions?

Hi, I read that notarization should be fairly quick. I thought that it was stuck, so I ended up sending a few submissions of the same app. I was wondering if you'd able to tell me the status of my latest submission (id: a094f93d-8bb2-47fe-a411-b6e357456ec7). It has been saying "In Progress" for over 3 hours now. If it is held for in-depth review, would you be able to tell me what's the wait period is like? Thanks!

Hey all, I’m experiencing a consistent issue with notarizing a signed .pkg file that contains a macOS screen saver (.saver) bundle. Nothing online so far except 1 thread on the form from the altool time pre-2023 so i thought it worth another update. Here is what I did: I signed the .saver bundle using my Developer ID Application certificate. I packaged it into a .pkg using pkgbuild with my Developer ID Installer certificate: I submitted the resulting .pkg via xcrun notarytool: xcrun notarytool submit saver-name.pkg --apple-id email@email.com --password [app-specific-password] --team-id xxxxxxxxx The submission appears to be accepted and uploads successfully. However, the notarization status remains stuck at “In Progress” for hours (over 12h), with no update. I also tried: Repackaging the .pkg with a new name using a zip Resubmitting it under a new submission ID All attempts are stuck in the same “In Progress” state indefinitely. Did anyone solve this yet?

I have two apps - say A and B in my AppStore account, deployed in the AppStore. App A has obtained the com.apple.developer.usernotifications.filtering entitlement and this is added to my AppStore account by Apple after approval. Note that this is added for the account, and not for the specific app. Now, my app B also wants this functionality. Followed all the steps as done for app A - adding the already approved entitlement to my app B's identifier, regenerating the profiles, adding the key in the entitlements file, calling the completion handler with empty content like - contentHandler(UNNotificationContent()) Still the notifications show, the filtering is not working. Do I have to request the entitlement for App B separately? Even if I do request again, I am not sure if there is going to be any difference in the steps already done. The difference can only be if Apple has a mapping with the app id internally in their system, for the filtering to work? If I have white-labelled versions of apps A or B, do I have to request again then? Or does Apple restrict only one app to have this entitlement from one AppStore account? Please guide on the next steps here.