Hi, I had an issue when I notarized myapplication.dmg with Process 'xcrun notarytool submit' exited with value '132'. Do you know how to solve it? Do you have any explanation about the response value when we execute 'xcrun notarytool submit'? Thank you very much! 2025-02-25 09:36:18,182 ERROR [org.ecl.cbi.ws.mac.not.xcr.not.NotarytoolNotarizer] (macos-notarization-service-pool-thread-14) Error while parsing the output after the upload of '/tmp/macos-notarization-service/pending-files/myapplication.dmg' to the Apple notarization service: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Premature end of file. at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204) at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1465) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1013) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825) at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224) at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:637) at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:326) at java.xml/javax.xml.parsers.SAXParser.parse(SAXParser.java:197) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.PListDict.fromXML(PListDict.java:134) at org.eclipse.cbi.ws.macos.notarization.xcrun.notarytool.NotarytoolNotarizer.analyzeSubmissionResult(NotarytoolNotarizer.java:39) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.NotarizationTool.upload(NotarizationTool.java:50) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.lambda$uploadFailsafe$3(Notarizer.java:65) at net.jodah.failsafe.Functions.lambda$get$0(Functions.java:48) at net.jodah.failsafe.RetryPolicyExecutor.lambda$supply$0(RetryPolicyExecutor.java:66) at net.jodah.failsafe.Execution.executeSync(Execution.java:128) at net.jodah.failsafe.FailsafeExecutor.call(FailsafeExecutor.java:379) at net.jodah.failsafe.FailsafeExecutor.get(FailsafeExecutor.java:68) at org.eclipse.cbi.ws.macos.notarization.xcrun.common.Notarizer.uploadFailsafe(Notarizer.java:65) at org.eclipse.cbi.ws.macos.notarization.NotarizationService.lambda$notarize$0(NotarizationService.java:192) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840)

I have some questions regarding App Group Id's and use of the FileManager during an Appstore iOS transfer. I've read a lot of the topics here that cover app groups and iOS, but it's still unclear exactly what is going to happen during transfer when we try to release an updated version of the app from the new account. We're using this method FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.foo.bar") to store files on the device that are important for app launch and user experience. Once we transfer the app and begin the process of creating a new version under the new account will we be able to read the files that are stored using this app group id under the new account? What steps do we need to take in order to handle this and continue being able to access these files? It seems like the app group is not transferred in the process? I've seen some users mention they removed the app group from the original account and created it again under the receiving account (with notes mentioning this is undocumented behavior). These conversations we're centered around Shared user defaults, and that applies as well but I'm more concerned with reading the values from the file system. Thanks!

I have read the posted solution threads and am still stuck with solving this issue. I have created a python app that works perfect on my machine and I would like to distribute externally via .zip file. I have created a certificate and downloaded it (G2 Sub-CA (Xcode 11.4.1 or later)) Next i have installed the Çert into the login keychain along with the Matching G2 Intermediate Cert (in system) and the proper Root Cert. However I am still not getting a proper chain when evaluating the developer certificate and I am at a loss at this point. I would love to pay someone to simply walk me through it if anyone has some time to solve this problem with me so I can run the notarytool and then distribute my application. Thanks!

I am managing provisioning profiles manually, including the one for my Notification Service Extension. I am wondering what happens if the provisioning profile for the Notification Service Extension expires. I have two types of apps: An App Store-distributed app An Enterprise-distributed app Can someone clarify how the expiration of the Notification Service Extension's provisioning profile affects both cases? Will the extension stop functioning, or will it continue to work normally?

I am trying to build/deploy app to my phone however I get this message: "provisioning profile doesn't include the currently selected device" My developer account is pretty old one and used to be one the paid-version one. My understanding is that I should be able to deploy apps using free account but I don't see where I can add or delete devices....stuck in the loop over here! :-) I've created support request via email but I don't know if that is being worked or not...four days since I put it in. I suppose my other options are new apple-id or pay $99 and hope apple pays attention then? Any other suggestions?

Hello, I have this simulator made in Unity that I want to distribute as Standalone. It consists of launcher which, when users download it, downloads the game. I've built the launcher, got Developer ID Application certificate, added entitlements from: https://docs.unity3d.com/Manual/macoscodesigning.html#signing-identity I've signed the .app of the launcher and 2 dlls chatgpt recommended to sign, zipped it, notarized .zip successfully, stapled to .app and put it on Google Drive to test. I got my other MacBook Pro, downloaded the zip, tried to open it. It did open, but there is a black loading screen saying "0% progress, 0B/0B" indicating that it isn't downloading anything - no network calling. When checked using command xattr -l path/to/file.app I get the following output: com.apple.macl: @?????I???|???? com.apple.quarantine: 0083;67bf1a22;Safari;69764595-CA94-44D2-B679-A69DC4669382 There are some specifics I think are also important to mention. I tried to code-sign it, notarize it and staple it using only Terminal and I'd like to keep it that way because I am very unfamiliar with Mac so I've avoided using Xcode as much as possible I really want to avoid putting the simulator up on the App Store, so I must have Standalone solution and Standalone solution only I believe that there might be problem with needing right entitlements, but I don't know how to check which one's are needed for users to avoid using "xattr" command in terminal to allow the launcher to run because of GateKeeper I've been banging my head against the wall with this problem for over a month and I don't see the light at the end of the tunnel.

I have a pass type id that expired. I created a CSR in keychain access on my Mac. I uploaded the CSR and generated a new cert. I downloaded the new cert and imported into keychain access. I don't see the associated private key and I cannot export a .p12 certificate. It's possible I started with the wrong key to generate the CSR or maybe I inadvertently deleted key while trying to locate the cert after importing. I'm not sure how to determine which. I do still have the private key from the cert that expired. But, I cannot figure out how to sign a cert again, my only option now is download. I've been searching the forum and while there may be an answer, I may just be looking for the wrong thing. I could use some help if anybody would be so kind.

Hey everyone, I’m wondering if anyone has run into any issues with this. Before I uploaded, I guess maybe 20 assets of 1080 x 720, my notarization was taking around 2-3 minutes almost instant. Now I’m looking at 30 minutes. I have no idea when the notarization is going to end. I’m wondering if asset size has any impact on notarization speed, and if so, is this going to be a one-time thing or is this going to happen with all my following builds? Let me know if anyone has run into anything similar or if the notarization service is just down right now. ⁠

I can't upload my macOS app to app store connect. Each time i try to upload, i see this message: Provisioning profile failed qualification Profile doesn't support App Groups. An empty app without an app group uploads fine, but if i add an app group to it, it does not upload.

Hello everyone, I’m currently developing an Electron application, and I’m trying to properly sign and notarize it for macOS. The notarization process itself seems to complete successfully—the file is accepted without issues. However, when I attempt to staple the notarization ticket to the executable, I consistently get Error 65 with TheStableAndValidateActionFailed. The issue is puzzling because the executable does not change at any point during the process. After facing this issue multiple times in my own project, I decided to test it on a more controlled setup. I followed the steps from this https://www.youtube.com/watch?v=hYBLfjT57hU and the instructions from this macos-code-signing-example which have previously worked for others. Yet, even with this setup, I still get the same Error 65. Below, I have attached the verbose logs for reference. I’m trying to understand what could be causing this issue—whether it’s related to certificates, the signing process, or something else entirely. Has anyone encountered a similar problem, and if so, how did you resolve it? Any insights would be greatly appreciated!

I am developing a macOS app that requires the Associated Domains entitlement. The app will be distributed as a custom app. The app needs to be signed using Team A’s Developer ID Application certificate and packaged under Team A’s Team ID. Team A has a secure signing and packaging setup, but they do not provide access to their Developer ID Application Identity (cert) or their provisioning profile. I am part of Team B and have access to Team B’s Developer ID Application identity and provisioning profiles. I am thinking of doing the following: I create a provisioning profile under Team B that authorizes the Associated Domains entitlement. I sign the app using Team B’s Developer ID Application identity, ensuring the required entitlements are included. Then, I re-sign the app using Team A’s Developer ID Application identity, since Team A has also set up the same bundle ID with the Associated Domains entitlement and corresponding provisioning profile. Questions: Is this approach correct & does it have any drawback? Will the double signing process work without issues, given that Team A has the required provisioning profile for the same bundle ID? Are there better ways to handle this situation where signing must be done under Team A but access is limited? Thanks!

From time to time I see folks run into error 65 when stapling a ticket to their notarised Mac software. This post explains the two common causes of that error. If you have questions or comments, start a new thread here on the forums. Put it in the Code Signing > Notarization topic area so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Error 65 When Stapling If you directly distribute Mac software, you must sign and notarise your product so that it passes Gatekeeper. For information on how to do this, see: Notarizing macOS software before distribution, if you use Xcode Creating distribution-signed code for macOS, Packaging Mac software for distribution, and Customizing the notarization workflow otherwise The last step of that process is to staple a ticket to your notarised product. This can fail with error 65. There are two common causes of that failure: No appropriate ticket Trust issues The following sections explain how to recognise and resolve these issues. Note You are not absolutely required to staple your product. See The Pros and Cons of Stapling for more on that topic. No Appropriate Ticket Consider the following stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/Desktop/TestError65 2025-03-03 22-12-47/TestError65.dmg CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/d812985247c75e94fd603f026991f96144a031af The staple and validate action failed! Error 65. Note the Record not found message. This indicates that the stapling operation failed because there’s no appropriate ticket. To investigate this, look at the notary log: % notarytool-log b53042b6-4cbb-4cef-ade4-dae034a69947 { … "status": "Accepted", … "sha256": "f012735a6d53b17082c088627da4249c9988111d17e7a90c49aa64ebc6bae22e", "ticketContents": [ { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg", "digestAlgorithm": "SHA-256", "cdhash": "01a553c91ee389764971767f5082ab8c7dcece02" } ], "issues": null } First, make sure that the status field is Accepted. If there’s some other value, the notary service didn’t generate a ticket at all! To understand why, look at the rest of the notary log for errors and warnings. Assuming that your notarisation request was successful, look through the log for cdhash values. These represent the contents of the ticket generated by the notary service. Compare that list to the cdhash values of the code being signed: % hdiutil attach "TestError65.dmg" … … /Volumes/Install TestError65 % codesign -d -vvv --arch arm64 "/Volumes/Install TestError65/TestError65.app" … CDHash=9627c72e53d44ae77513613e2ce33314bd5ef41e … % codesign -d -vvv --arch x86_64 "/Volumes/Install TestError65/TestError65.app" … CDHash=abc27b0f2daee77b9316de3c6844fbd9e234621c … Those are all present in the ticket. However, consider the cdhash of the disk image itself: % codesign -d -vvv "TestError65.dmg" … CDHash=d812985247c75e94fd603f026991f96144a031af … That’s the cdhash that stapler is looking for: CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". But it’s not present in the notarised ticket. Note The term cdhash stands for code directory hash. If you’re curious what that’s about, see TN3126 Inside Code Signing: Hashes and the Notarisation Fundamentals DevForums post. What happened here is: I built the app. I signed it with my Developer ID code-signing identity. I created a disk image from that app. I signed that with my Developer ID code-signing identity. I notarised that. I then re-signed the disk image. This changes the cdhash in the code signature. Now the disk image’s cdhash doesn’t match the cdhash in the ticket, so stapling fails. To resolve this problem, make sure you’re stapling exactly the file that you submitted to the notary service. One good option is to compare the SHA-256 hash of the file you’re working on with the sha256 field in the notary log. Trust Issues Now consider this stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/TestError65.dmg Could not validate ticket for /Users/quinn/TestError65.dmg The staple and validate action failed! Error 65. Note how it’s different from the previous one. Rather than saying that the ticket was not found, it says Could not validate ticket. So, stapler found the ticket for the file and then tried to validate it before doing the staple operation. That validation failed, and thus this error. The most common cause of this problem is folks messing around with trust settings. Consider this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. Contrast it with this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d Number of trusted certs = 1 Cert 0: Apple Root CA - G3 Number of trust settings : 10 … Someone has tweaked the trust settings for the Apple Root CA - G3 anchor. In fact, I used Keychain Access to mark the certificate as Always Trust. You’d think that’d avoid problems, but you’d be wrong. Our code signing machinery expects Apple’s anchor and intermediate certificates to have the default trust settings. IMPORTANT Some trust settings overrides are fine. For example, on my main work Mac there are trust settings overrides for Apple internal anchors. This problem occurs when there are trust settings overrides for Apple’s standard anchor and intermediate certificates. To fix this: In Terminal, run the dump-trust-settings commands shown above and build a list of Apple certificates with trust settings overrides. In Keychain Access, find the first problematic certificate in your list. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, close the window and move on to step 8. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Repeat steps until 2 through 7 for each of the problematic certificates you found in step 1. When you’re done, run the dump-trust-settings commands again to confirm that your changes took effect.

After upgrading the iOS system to 18.3.1, the APP crashed continuously when it was launched. The following log was seen in the device log： Bootstrapping failed for <FBApplicationProcess: 0x72ad16b80; app<com.xxxx.yyyy>:> with error: <NSError: 0x300cd4d80; domain: RBSRequestErrorDomain; code: 5; "Launch failed."> { NSUnderlyingError = <NSError: 0x300cd4ab0; domain: NSPOSIXErrorDomain; code: 85> { NSLocalizedDescription = Launchd job spawn failed; }; } Our APP is in-house distribution What are the possible causes? How can I solve it?

Hello everyone, I'm encountering significant delays with the notarization process for our Electron application using a newly created developer account. The process is taking an unusually long time (1-2 days), which is disrupting our workflow. Details: We've attempted notarization multiple times over the past 2 weeks. The process consistently takes 8+ hours before I typically abort it. (due going offline etc) Interestingly, when I check the notary history later, it shows the notarization was actually successful. Our application package is relatively large, which might be contributing to the delay (archive: 226 mb, app:800mb) Recent Examples: Current submission (still in progress): 52db12c3-4a54-4e14-9d77-e141d7f28227 Previous successful submission: 49273be6-3e13-4f3f-83a4-945114d899b9 Has anyone else experienced similar issues with notarizing applications? Are there any optimizations or best practices I should implement to reduce these processing times? I'm using the default notarization feature that comes with electron forge. Any suggestions or insights would be greatly appreciated!

Hey all, I'm experiencing an error, when trying to upload my app to the App Store using Transporter. I build my app with fvm flutter build ipa --release. When I try to upload this, I get the following error: I have already done a rebuild and checked my Provision Profile and certificate

Hello, I’m facing an issue with enabling In-App Purchases (IAP) for my iOS app, and it’s causing provisioning errors during the build process. Issue: • In Apple Developer Portal → Certificates, Identifiers & Profiles, the In-App Purchase capability is checked but grayed out, so I can’t modify it. • In Xcode, under Signing & Capabilities, I don’t see In-App Purchase listed. • When trying to build, I get the following error: Provisioning profile “BillionMines_Dev_Profile” doesn’t include the com.apple.developer.in-app-purchase entitlement. • Automatic signing in Xcode fails with: Xcode failed to provision this target. What I Have Tried: 1. Verified that my App ID is explicitly defined (not a wildcard ID). 2. Regenerated and downloaded a new Provisioning Profile, ensuring it matches my app. 3. Confirmed that In-App Purchase is enabled in App Store Connect under Features. 4. Cleaned the build folder and restarted Xcode. 5. Manually added com.apple.developer.in-app-purchase to my .entitlements file. Questions: • Why is the In-App Purchase option grayed out in Certificates, Identifiers & Profiles? • How can I ensure my provisioning profile includes the com.apple.developer.in-app-purchase entitlement? • Are there additional steps required to fully activate In-App Purchases? Any help would be greatly appreciated! Thanks in advance.

The mentioned way of setting up complications does not work. We can't create the identifier according to the guideline mentioned in the WWDC session. https://developer.apple.com/videos/play/wwdc2020/10049/?time=1021 Timestamp: 17:04 Error: An attribute in the provided entity has invalid value An App ID with Identifier '.watchkitapp.complication' is not available. Please enter a different string. To clarify - the non masked identifier is not used on another property inside our dev program. Without creating the identifier our tests result in not working push notifications. Error message while testing: discarded as application was not registered. Is the way mentioned in the WWDC session still valid? BR

Hello, We use automatic signing and Fastlane on our CI. Fastlane uses xcodebuild to create an archive. xcodebuild -workspace ourApp.xcworkspace -scheme app-dev -destination generic/platform=iOS -archivePath app-dev.xcarchive -skipPackagePluginValidation -allowProvisioningUpdates -authenticationKeyID OurAppStoreConnectAuthKey -authenticationKeyIssuerID OurAppStoreConnectAuthKeyIssuerId -authenticationKeyPath /path/to/OurAppStoreConnectKey.p8 clean archive All works fine, but .... Why does Xcode 16 log out logged Apple ID and create a new every build? As a result, we have more and more Unknown Apple IDs in Xcode, and for each of them an error appears in log. Error: xcodebuild[3174:1804334] DVTDeveloperAccountManager: Failed to load credentials for 0A1DF15C-ETC-ETC: Error Domain=DVTDeveloperAccountCredentialsError Code=0 "Invalid credentials in keychain for 0A1DF15C-ETC-ETC, missing Xcode-Username" UserInfo={NSLocalizedDescription=Invalid credentials in keychain for 0A1DF15C-ETC-ETC, missing Xcode-Username} Of course, the originally logged-in Apple ID has an error corresponding to his non-logged-in state. xcodebuild[3174:1804334] DVTDeveloperAccountManager: Failed to load credentials for originally_logged-in_user: Error Domain=DVTDeveloperAccountCredentialsError Code=0 "Invalid credentials in keychain for originally_logged-in_user, missing Xcode-Token" UserInfo={NSLocalizedDescription=Invalid credentials in keychain for originally_logged-in_user, missing Xcode-Token} Why does this happen and how can it be fixed? Why does Xcode 16 log out its logged Apple ID?

I am subscribed to an individual developer license. https://developer.apple.com/documentation/xcode/configuring-network-extensions "Network Extension" does not appear in the Capability section in Xcode. Below is my Xcode screenshot.

We are developing an application for MAC machine using .NET. After developing and signing the package in notarization process was failed with the error in the attached file. Then we have created the simple Xamarin.MAC to check whether able to notarize it . But with the simple project also we have faced the same error. Provide us the solution to fix these issues We have tried to codesiginin the app to resolve the notarization error, but while code signing the below error was thrown "unable to build chain to self-signed root for signer "Developer ID Application" (not mentioning the certificate id) SFSecure.app: errSecInternalComponent" Notarization-error