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)

Hi everyone, We're experiencing a critical and persistent code signing failure (HTTP 403) after accepting the latest Apple Developer Agreement, blocking our application release. Problem: Despite confirming the new Apple Developer Agreement is signed and active on the portal, code signing attempts return an HTTP 403 error, stating a "required agreement is missing or has expired." Steps Taken: Accepted new Apple Developer Agreement. Verified active developer membership and valid certificates (good for years). Cleared caches, restarted systems. Confirmed Team ID, Apple ID, and provisioning profile validity. Any help is greatly appreciated, its been stuck for more than 2 days now.

Hi, I am developing a iOS app with Packet Tunnel Provider Network Extension. I manage signing manually. I created a distribution provisioning profile. Then when I archive and click "validate" I get this error: Your application bundle's signature contains code signing entitlements that are not supported on iOS. Specifically, value 'url-filter-provider' for key 'com.apple.developer.networking.networkextension' So I run security cms -D -i profiles/vpn_distribution.mobileprovision and I see there <key>Entitlements</key> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>app-proxy-provider</string> <string>content-filter-provider</string> <string>packet-tunnel-provider</string> <string>dns-proxy</string> <string>dns-settings</string> <string>relay</string> <string>url-filter-provider</string> <string>hotspot-provider</string> </array> Where are those coming from. My entitlement file has <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider</string> </array> <key>com.apple.security.application-groups</key> <array> <string>group.my-app-group</string> </array> </dict> </plist> What is happening here. How can I get a provisioning profile that only has the entitlements that I actually need?

I have 14 total devices, from way back. I am currently in a financial bind and can't renew just yet. BUT I am at past my time to reset the device list back to zero. But the screen to do that is behind the paid account. Catch 22 Can we fix it? As it stands I must email tech support, but this is a bug so I posted

I am building an electron app bundled with python. My code signing was fast, but when it came to notarization, it has already taken over 6+ hours. How can I speed things up?

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

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.

So I just updated Xcode to 16.3 and updated a project to its recommended build settings which includes "Register App Groups". So I have an outside Mac App Store app that uses app groups. Here we have an action extension. I can't debug it, can't get it to run. Nothing useful in Xcode is displayed when I try... but it looks like a code signing issue when I run and have Console open. So I try to make a provisioning profile manually and set it...didn't work. I noticed now though in signing & capabilities the group id is in red...like it's invalid, or something? This was a "macOS styled" group without the "group." prefix. So am I supposed to switch it to have the group. prefix? It makes the red text go away (no warnings or anything about app groups here, just red text). So if I change it to group. prefix..does that make an entire new container?What happens on app update for installs that don't have group. prefix? Does the system transparently migrate the group? Or Am I supposed to migrate the entire group container to the identifier with group. prefix? Also how does this affect running on older version of macOS? If I go with the "group." prefix to make the red text go away,.. what happens on macOS 11.0? Got a little more than I bargained for here after midnight.

When building to macOS on GameMaker, I get the error "this identity cannot be used for signing code" when using the Developer ID Installer certificate. The certificate was neither expired nor revoked, but nonetheless I created new certificates to start fresh but am still getting that error. I don't get issues building to iOS via GameMaker, just to macOS. If it makes any difference, I only noticed this issue started happening after I converted my Apple Developer Program account from an individual account to an organizational account, although it was weeks to months before I built to macOS via GameMaker before then, so I don't know if it correlates with that.

I'm trying to get an app notarized, which fails with this error: The signature of the binary is invalid. However, locally checking the signature does succeed: $ codesign -vvv --deep --strict TheApp.app […] TheApp.app: valid on disk TheApp.app: satisfies its Designated Requirement Performing this check on every single item in the app's MacOS folder also succeeds. Context: embedded prebuilt binaries Now, the app has something unusual about it: it embeds prebuilt binaries, arranged in various nested folders. So, the app bundle's MacOS folder actually contains another folder with a whole tree of executables and libraries: Removing these (before building) does fix the notarization issue, but obviously I'd like to keep them in. I did my best to properly sign these items: At build time, they're copied into the product by a Copy Files phase (but not signed), then signed by a script phase That signing uses the same signing identity as the running Xcode build, and enables the hardened runtime The app builds and runs correctly, even as a release build The app has runtime hardening and app sandbox enabled How should I go about diagnosing the notarization issue?

I have a macOS application that was previously distributed under my personal Apple Developer account using a Developer ID certificate. We’ve recently transitioned distribution to our company’s Apple Developer account. The app’s bundle identifier has been successfully transferred, and I’ve signed a new build of the app using the company’s Developer ID certificate. The app installs and runs correctly under the new signature. However, I’ve encountered a problem: the app is no longer able to access previously granted permissions (e.g., Screen Recording, System Audio Recording, and Input Monitoring). Furthermore, it cannot re-prompt for these permissions because they appear as already granted in System Settings. From what I understand, this issue is due to the change in the code signing identity. Specifically, the designated requirements used by macOS to identify an app have changed, so the system no longer associates the new version of the app with the previously granted permissions (as outlined in Apple's Technical Note TN3127). The only workaround I’ve found so far is to manually reset the app's permissions using Terminal commands (e.g., tccutil reset), but this is not something we can reasonably ask end users to do. Question: Is there a recommended or supported approach to either preserve permissions when changing Developer ID identities, or programmatically trigger a permissions reset for existing users? We're looking for a seamless solution that doesn't degrade user experience.

I have local LLM application, the backend is in python and frontend is in electron.js , all complied in a .pkg file or .dmg file I have created the valid certifcates for notarization But it fails everytime, I have attached the logs steps I followed Created a certificate all steps related to getting it setup, ran productsign command on pkg file ran codesign for dmg xcruntool submit command If anyone has any idea on how proceed codesigningdmg (2).txt code-singingpkg.txt

I’ve developed a macOS app, but I’ve had trouble using a script to fully codesign it and package it into a .dmg file. I was only able to complete codesigning using the third-party app itself—not via command-line scripts. Is it possible to write a script that automates the entire process of codesigning the app? To provide the best user experience for those downloading the app outside of the Mac App Store, is it correct to first package it as a .app and then wrap that into a .dmg file for distribution? Currently, the app is available on the web as a .dmg. When downloaded, it appears in a folder and can be double-clicked to launch. However, macOS displays a warning that it was downloaded from the internet. Can I use a script to remove that quarantine warning? If possible, I’d appreciate a step-by-step explanation and a sample command-line script to: Codesign the app properly Package it into a signed .dmg Remove the quarantine attribute for local testing or distribution Is the reason I was only able to codesign it inside the third-party app due to how that app was built, or can this always be done from the command line?

To learn how to develop/distribute a DriverKit driver (DEXT) and a UserClient app correctly, I am trying to run the following sample dext and app. https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app?language=objc I walked throught steps in README.md included in the project and faced issues. First, I referred the "Configure the Sample Code Project" section in the README.md and configured the sample code project to build with automatic signing. I could run the app and activate the dext successfully and made sure the app could communicate with the dext. Next, I tried the manual signing. I followed steps described in the "Configure the Sample Code Project" section carefully. The following entitlements has already been assigned to my team account. DriverKit Allow Any UserClient Access DriverKit USB Transport - VendorID DriverKit I could build both app and dext and could run the app. However, when I clicked the "Install Dext" button to activate the dext, I got the following error: sysex didFailWithError: extension category returned error Am I missing something? I would also like to know detailed steps to publicly distribute my dext and app using our Developer ID Application Certificate, as README.md only shows how to configure the project for development. Xcode version: 16.3 (16E140) Development OS: macOS 15.5 (24F74) Target OS: macOS 15.5 (24F74)

I am facing this error on every flutter project build. Although it runs ok. The error happens on the codesign command What do I need to fix ? I have validated that every *.plist file is ok using plutil -lint ERROR MESSAGE /usr/bin/codesign --force --sign MY_SHA_CODE --verbose /Users/macbookair/workspace/flutter_application_1/build/ios/Release-iphoneos/Runner.app/Frameworks/libswiftCore.dylib)` exited with status 0. The command's output was: /Users/macbookair/workspace/flutter_application_1/build/ios/Release-iphoneos/Runner.app/Frameworks/libswiftCore.dylib: a required plist file or resource is malformed Info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleDisplayName</key> <string>Flutter Application 1</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>flutter_application_1</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleShortVersionString</key> <string>$(FLUTTER_BUILD_NAME)</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>$(FLUTTER_BUILD_NUMBER)</string> <key>LSRequiresIPhoneOS</key> <true/> <key>UILaunchStoryboardName</key> <string>LaunchScreen</string> <key>UIMainStoryboardFile</key> <string>Main</string> <key>UISupportedInterfaceOrientations</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>UISupportedInterfaceOrientations~ipad</key> <array> <string>UIInterfaceOrientationPortrait</string> <string>UIInterfaceOrientationPortraitUpsideDown</string> <string>UIInterfaceOrientationLandscapeLeft</string> <string>UIInterfaceOrientationLandscapeRight</string> </array> <key>CADisableMinimumFrameDurationOnPhone</key> <true/> <key>UIApplicationSupportsIndirectInputEvents</key> <true/></dict> </plist> Please help.

Hi there, We've discovered a problem with our iOS app. We've been attempting to add a Driverkit driver to it, but any time we run the app through Testflight, the driver installs fine, but when we go to enable the driver toggle in the app's settings, the toggle stays on, but in the device logs I can see: could not insert bundle at <private> into manager: <private> As you would expect - this means the driver is not actually enabled and does not respond to a device being connected to the iPad. This does not happen when building & running the app locally, nor does it happen when installing an Ad Hoc build. We also have a different app, not yet shipped. We are able to add the driver to that app without issue. It works after going through Testflight. What we have discovered now is that everything works fine even if we just create an entirely new app with it's own bundle IDs. I should point out that in all cases, we're keeping the capabilities the same for each of these apps/IDs - including the managed capabilities. The bundle IDs that have this problem are older (5 years old or more). It seems like any newer ID will work, but trying to add the driver (and the associated managed capabilities) to an older app/ID results in this vague error message, with no further details. If we inspect the resulting dexts, we can also see that the "Internal requirements code size" is different on the ones that fail. The failing ones have a size of 204 bytes, whereas the working ones all have a size of 220 bytes. Not sure if that's related but it's strikingly consistent. Does this mean there is an issue with older app IDs, and we need Apple to manually refresh them in some way before the driverkit capabilities will work after going through Testflight? We have two apps in this state, both are of the same vintage (~5 years+). We've been battling this issue for months on and off, so would appreciate some help.

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?

Once I have built my macOS .app and signed it I run notarytool using this simple shell script: #!/bin/sh ditto -c -k --keepParent "$1.app" "$1.zip" xcrun notarytool submit "$1.zip" --keychain-profile "Notary Profile for DeepSkyStacker" --wait xcrun stapler staple $1.app rm -f $1.zip How can I export that "keychain-profile" (notary profile) so I can use it in CI/CD actions? Clearly I don't wish to expose the full invocation of xcrun notarytool store-credentials.

I have a misterous problem with checking DMG notarization. It fails: bash-3.2$ spctl -a -t open --context context:primary-signature -v MyApp.dmg MyApp: rejected source=no usable signature However this DMG installs fine on Big Sur 11.2.2, macOS allows to run this app, and checking of notarization for installed app was passed: bash-3.2$ spctl -a -v '/Applications/MyApp.app' /Applications/MyApp.app: accepted source=Notarized Developer ID I checked other downloaded apps (Intel or Universal). Some DMG files pass DMG notarization (for example, Audacity), and some fails (PerfectTablePlan). Why? For my app (Universal) I use the following code to codesign and notarize: codesign --timestamp --options runtime --force --deep -s "Developer ID Application: MYCOMPANY" "My.app" // Creating DMG with EULA license xcrun altool --notarize-app --primary-bundle-id MyApp -u "my@email.com" -p "abc123" --file MyApp.dmg xcrun stapler staple MyApp.dmg

In the past it was relatively easy to download from the developer portal both the app signing and installer signing certs so that I could sign AppleScripts from Script Editor when exporting them and when building packages in Jamf Composer. I went to set that up today and it seems things have changed in the last few years since I've had to set this up. I've been unable to sort this out and would love some help. I'm looking for a tutorial on doing this that walks someone step-by-step through the process for obtaining the certs (yes, I have dev account) and setting them up in keychain and then making use of them. Thanks!