I regularly see folks confused by the difference in behaviour of app groups between macOS and iOS. There have been substantial changes in this space recently. While much of this is now covered in the official docs (r. 92322409), I’ve updated this post to go into all the gory details. If you have questions or comments, start a new thread with the details. Put it in the App & System Services > Core OS topic area and tag it with Code Signing and Entitlements. Oh, and if your question is about app group containers, also include Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Groups: macOS vs iOS: Working Towards Harmony There are two styles of app group ID: iOS-style app group IDs start with group., for example, group.eskimo1.test. macOS-style app group IDs start with your Team ID, for example, SKMME9E2Y8.eskimo1.test. This difference has been the source of numerous weird problems over the years. Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS for all product types [1]. If you’re writing new code that uses app groups, use an iOS-style app group ID. If you have existing code that uses a macOS-style app group ID, consider how you might transition to the iOS style. IMPORTANT The Feb 2025 changes aren’t tied to an OS release but rather to a Developer website update. For more on this, see Feb 2025 Changes, below. [1] If your product is a standalone executable, like a daemon or agent, wrap it in an app-like structure, as explained in Signing a daemon with a restricted entitlement. iOS-Style App Group IDs An iOS-style app group ID has the following features: It starts with the group. prefix, for example, group.eskimo1.test. You allocate it on the Developer website. This assigns the app group ID to your team. You then claim access to it by listing it in the App Groups entitlement (com.apple.security.application-groups) entitlement. That claim must be authorised by a provisioning profile [1]. The Developer website will only let you include your team’s app group IDs in your profile. For more background on provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. iOS-style app group IDs originated on iOS with iOS 3.0. They’ve always been supported on iOS’s child platforms (iPadOS, tvOS, visionOS, and watchOS). On the Mac: They’ve been supported by Mac Catalyst since that technology was introduced. Likewise for iOS Apps on Mac. Starting in Feb 2025, they’re supported for other Mac products. [1] Strictly speaking macOS does not require that, but if your claim is not authorised by a profile then you might run into other problems. See Entitlements-Validated Flag, below. macOS-Style App Group IDs A macOS-style app group ID has the following features: It should start with your Team ID [1], for example, SKMME9E2Y8.eskimo1.test. It can’t be explicitly allocated on the Developer website. Code that isn’t sandboxed doesn’t need to claim the app group ID in the App Groups entitlement. [2] To use an app group, claim the app group ID in the App Groups entitlement. The App Groups entitlement is not restricted on macOS, meaning that this claim doesn’t need to be authorised by a provisioning profile [3]. However, if you claim an app group ID that’s not authorised in some way, you might run into problems. More on that later in this post. If you submit an app to the Mac App Store, the submission process checks that your app group IDs make sense, that is, they either start with your Team ID (macOS style) or are assigned to your team (iOS style). [1] This is “should” because, historically, macOS has not actually required it. However, that’s now changing, with things like app group container protection. [2] This was true prior to macOS 15. It may still technically be true in macOS 15 and later, but the most important thing, access to the app group container, requires the entitlement because of app group container protection. [3] Technically it’s a validation-required entitlement, something that we’ll come back to in the Entitlements-Validated Flag section. Feb 2025 Changes On 21 Feb 2025 we rolled out a change to the Developer website that completes the support for iOS-style app group IDs on the Mac. Specifically, it’s now possible to create a Mac provisioning profile that authorises the use of an iOS-style app group ID. Note This change doesn’t affect Mac Catalyst or iOS Apps on Mac, which have always been able to use iOS-style app group IDs on the Mac. Prior to this change it was possible to use an iOS-style app group ID on the Mac but that might result in some weird behaviour. Later sections of this post describe some of those problems. Of course, that information is now only of historical interest because, if you’re using an iOS-style app group, you can and should authorise that use with a provisioning profile. We also started seeding Xcode 16.3, which has since been release. This is aware of the Developer website change, and its Signing & Capabilities editor actively encourages you to use iOS-style app groups IDs in all products. Note This Xcode behaviour is the only option for iOS and its child platforms. With Xcode 16.3, it’s now the default for macOS as well. If you have existing project, enable this behaviour using the Register App Groups build setting. Finally, we updated a number of app group documentation pages, including App Groups entitlement and Configuring app groups. Crossing the Streams In some circumstances you might need to have a single app that accesses both an iOS- and a macOS-style app group. For example: You have a macOS app. You want to migrate to an iOS-style app group ID, perhaps because you want to share an app group container with a Mac Catalyst app. But you also need to access existing content in a container identified by a macOS-style app group ID. Historically this caused problems (FB16664827) but, as of Jun 2025, this is fully supported (r. 148552377). When the Developer website generates a Mac provisioning profile for an App ID with the App Groups capability, it automatically adds TEAM_ID.* to the list of app group IDs authorised by that profile (where TEAM_ID is your Team ID). This allows the app to claim access to every iOS-style app group ID associated with the App ID and any macOS-style app group IDs for that team. This helps in two circumstances: It avoids any Mac App Store Connect submission problems, because App Store Connect can see that the app’s profile authorises its use of all the it app group IDs it claims access to. Outside of App Store — for example, when you directly distribute an app using Developer ID signing — you no longer have to rely on macOS granting implicit access to macOS-style app group IDs. Rather, such access is explicitly authorised by your profile. That ensures that your entitlements remain validated, as discussed in the Entitlements-Validated Flag, below. A Historical Interlude These different styles of app group IDs have historical roots: On iOS, third-party apps have always used provisioning profiles, and thus the App Groups entitlement is restricted just like any other entitlement. On macOS, support for app groups was introduced before macOS had general support for provisioning profiles [1], and thus the App Groups entitlement is unrestricted. The unrestricted nature of this entitlement poses two problems. The first is accidental collisions. How do you prevent folks from accidentally using an app group ID that’s in use by some other developer? On iOS this is easy: The Developer website assigns each app group ID to a specific team, which guarantees uniqueness. macOS achieved a similar result by using the Team ID as a prefix. The second problem is malicious reuse. How do you prevent a Mac app from accessing the app group containers of some other team? Again, this isn’t an issue on iOS because the App Groups entitlement is restricted. On macOS the solution was for the Mac App Store to prevent you from publishing an app that used an app group ID that’s used by another team. However, this only works for Mac App Store apps. Directly distributed apps were free to access app group containers of any other app. That was considered acceptable back when the Mac App Store was first introduced. That’s no longer the case, which is why macOS 15 introduced app group container protection. See App Group Container Protection, below. [1] I’m specifically talking about provisioning profiles for directly distributed apps, that is, apps using Developer ID signing. Entitlements-Validated Flag The fact that the App Groups entitlement is unrestricted on macOS is, when you think about it, a little odd. The purpose of entitlements is to gate access to functionality. If an entitlement isn’t restricted, it’s not much of a gate! For most unrestricted entitlements that’s not a problem. Specifically, for both the App Sandbox and Hardened Runtime entitlements, those are things you opt in to, so macOS is happy to accept the entitlement at face value. After all, if you want to cheat you can just not opt in [1]. However, this isn’t the case for the App Groups entitlement, which actually gates access to functionality. Dealing with this requires macOS to walk a fine line between security and compatibility. Part of that solution is the entitlements-validated flag. When a process runs an executable, macOS checks its entitlements. There are two categories: Restricted entitlements must be authorised by a provisioning profile. If your process runs an executable that claims a restricted entitlement that’s not authorised by a profile, the system traps. Unrestricted entitlements don’t have to be authorised by a provisioning profile; they can be used by any code at any time. However, the App Groups entitlement is a special type of unrestricted entitlement called a validation-required entitlement. If a process runs an executable that claims a validation-required entitlement and that claim is not authorised by a profile, the system allows the process to continue running but clears its entitlements-validated flag. Some subsystems gate functionality on the entitlements-validated flag. For example, the data protection keychain uses entitlements as part of its access control model, but refuses to honour those entitlements if the entitlement-validated flag has been cleared. Note If you’re curious about this flag, use the procinfo subcommand of launchctl to view it. For example: % sudo launchctl procinfo `pgrep Test20230126` … code signing info = valid … entitlements validated … If the flag has been cleared, this line will be missing from the code signing info section. Historically this was a serious problem because it prevented you from creating an app that uses both app groups and the data protection keychain [2] (r. 104859788). Fortunately that’s no longer an issue because the Developer website now lets you include the App Groups entitlement in macOS provisioning profiles. [1] From the perspective of macOS checking entitlements at runtime. There are other checks: The App Sandbox is mandatory for Mac App Store apps, but that’s checked when you upload the app to App Store Connect. Directly distributed apps must be notarised to pass Gatekeeper, and the notary service requires that all executables enable the hardened runtime. [2] See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. App Groups and the Keychain The differences described above explain a historical oddity associated with keychain access. The Sharing access to keychain items among a collection of apps article says: Application groups When you collect related apps into an application group using the App Groups entitlement, they share access to a group container, and gain the ability to message each other in certain ways. You can use app group names as keychain access group names, without adding them to the Keychain Access Groups entitlement. On iOS this makes a lot of sense: The App Groups entitlement is a restricted entitlement on iOS. The Developer website assigns each iOS-style app group ID to a specific team, which guarantees uniqueness. The required group. prefix means that these keychain access groups can’t collide with other keychain access groups, which all start with an App ID prefix (there’s also Apple-only keychain access groups that start with other prefixes, like apple). However, this didn’t work on macOS [1] because the App Groups entitlement is unrestricted there. However, with the Feb 2025 changes it should now be possible to use an iOS-style app group ID as a keychain access group on macOS. Note I say “should” because I’ve not actually tried it (-: Keep in mind that standard keychain access groups are protected the same way on all platforms, using the restricted Keychain Access Groups entitlement (keychain-access-groups). [1] Except for Mac Catalyst apps and iOS Apps on Mac. Not Entirely Unsatisfied When you launch a Mac app that uses app groups you might see this log entry: type: error time: 10:41:35.858009+0000 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.Test92322409: Unsatisfied entitlements: com.apple.security.application-groups Note The exact format of that log entry, and the circumstances under which it’s generated, varies by platform. On macOS 13.0.1 I was able to generate it by running a sandboxed app that claims a macOS-style app group ID in the App Groups entitlement and also claims some other restricted entitlement. This looks kinda worrying and can be the source of problems. It means that the App Groups entitlement claims an entitlement that’s not authorised by a provisioning profile. On iOS this would trap, but on macOS the system allows the process to continue running. It does, however, clear the entitlements-validate flag. See Entitlements-Validated Flag for an in-depth discussion of this. The easiest way to avoid this problem is to authorise your app group ID claims with a provisioning profile. If there’s some reason you can’t do that, watch out for potential problems with: The data protection keychain — See the discussion of that in the Entitlements-Validated Flag and App Groups and the Keychain sections, both above. App group container protection — See App Group Container Protection, below. App Group Container Protection macOS 15 introduced app group container protection. To access an app group container without user intervention: Claim access to the app group by listing its ID in the App Groups entitlement. Locate the container by calling the containerURL(forSecurityApplicationGroupIdentifier:) method. Ensure that at least one of the following criteria are met: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. If your app doesn’t follow these rules, the system prompts the user to approve its access to the container. If granted, that consent applies only for the duration of that app instance. For more on this, see: The System Integrity Protection section of the macOS Sequoia 15 Release Notes The System Integrity Protection section of the macOS Sequoia 15.1 Release Notes WWDC 2024 Session 10123 What’s new in privacy, starting at 12:23 The above criteria mean that you rarely run into the app group authorisation prompt. If you encounter a case where that happens, feel free to start a thread here on DevForums. See the top of this post for info on the topic and tags to use. Note Prior to the Feb 2025 change, things generally worked out fine when you app was deployed but you might’ve run into problems during development. That’s no longer the case. [1] This is what allows Mac Catalyst and iOS Apps on Mac to work. Revision History 2025-08-12 Added a reference to the Register App Groups build setting. 2025-07-28 Updated the Crossing the Streams section for the Jun 2025 change. Made other minor editorial changes. 2025-04-16 Rewrote the document now that iOS-style app group IDs are fully supported on the Mac. Changed the title from App Groups: macOS vs iOS: Fight! to App Groups: macOS vs iOS: Working Towards Harmony 2025-02-25 Fixed the Xcode version number mentioned in yesterday’s update. 2025-02-24 Added a quick update about the iOS-style app group IDs on macOS issue. 2024-11-05 Further clarified app group container protection. Reworked some other sections to account for this new reality. 2024-10-29 Clarified the points in App Group Container Protection. 2024-10-23 Fleshed out the discussion of app group container protection on macOS 15. 2024-09-04 Added information about app group container protection on macOS 15. 2023-01-31 Renamed the Not Entirely Unsatisfactory section to Not Entirely Unsatisfied. Updated it to describe the real impact of that log message. 2022-12-12 First posted.

I'm currently befuddled by the entire signing and certificate process. I don't understand what I need, what the team admin needs to do, or how to go about doing it so that I can build the project. We've managed to have this working in the past but I guess the system has changed somewhat. Here's what we have going: A Unity project which hasn't changed from a few years ago. I build the project in unity, open the Xcode project and this: There's an issue with the Signing and Capabilities. If I choose automatic setup it shows an error saying that it requires a development team. I had the account admin add my Apple ID to the team so I'm not sure why that's an issue still. Do I need to pay the 99$ to be able to building Xcode? If I try to do it manually I select the provisioning profile that the account admin sent me and it auto selects the team associated with the provisioning profile I guess but then there's no singing certificate. The error says: There is no signing certificate "iOS Development" found. No "iOS Development" signing certificate matching team ID "V7D5YBZRMV" with a private key was found. So, if someone could explain to me like I'm 5 the entire signing and certificate process is and let me know what we're doing wrong with the team/provisioning profile/certificate setup I would be very much appreciative.

Our app .dmg file was successfully code signed. We then revised the app and created a new .dmg. Running codesign gave an "app is already signed" message. Then running codesign -dv said "code object is not signed at all" Older solutions said to use -f to force signing, but that is no longer an option.

Hello, I'm currently trying to upload a new version of an existing application. But each time I try to validate the archive of the application, I got the following error in Xcode (v16.2) : Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “37CG5MY799.com.example.app” value for the com.apple.application-identifier key in “com.example.app.pkg/Payload/app.app/Contents/MacOS/app” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. I suspect that there is a problem with the App ID Prefix (that is 37CG5MY799 for the app) when our team ID is E4R7RJ7LA3 but I cannot find a solution. I asked the Apple Developer Support for help and I have read the documentation they sent but it couldn't solve this problem so they redirected me to the forums. https://developer.apple.com/library/archive/qa/qa1879/_index.html https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-OVERVIEW https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG33 There isn't any obvious App ID Prefix mismatch in the entitlement between the Application's signature entitlement and the Embedded provisioning profile entitlement . Application's signature entitlement : <dict> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> Embedded provisioning profile entitlement : <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> <string>E4R7RJ7LA3.*</string> </array> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>keychain-access-groups</key> <array> <string>37CG5MY799.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> </dict> The app also have a browser extension that correctly use the Team ID. How to solve this problem ? Thanks for your time, Qeg

I have an app that I signed and distribute between some internal testflight users. Potentially I want to invite some 'Public' beta testers which don't need to validate (_World have read rights in the public database) Question: Do I need to have a working public CloudKit , when users are invited through TestFlight, or are they going to test on the development container? I understand that when I invite beta-tester without authorization (external testers) they cannot access the developer container, so therefore I need to have the production CloudKit container up and running. I have tried to populate the public production container, but for whatever reason my upload app still goes to the development container. I have archived the app, and tried, but no luck. I let xcode manage my certificates/profiles. but what do I need to change to be able to use my upload file to upload the production container, instead of the development. I tried: init() { container = CKContainer(identifier: "iCloud.com.xxxx.xxxx") publicDB = container.publicCloudDatabase I got no error in the console, but data is always populated to the development database, instead the production. I tried to create a provisioning profile, but for some reason Xcode doesn't like it. Tried to create one a different provisioning profile manual through the developer portal, for the app. but xcode doesn't want to use that, and mentions that the requirement are already in place. What can I check/do to solve this.

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.

Hi everyone, I have a macOS application that uses Screen Recording permission. I build my app with an adhoc signature (not with a Developer ID certificate). For example, in version 1.0.0, I grant Screen Recording permission to the app. Later, I build a new version (1.1.0) and update by dragging the new app into the Applications folder to overwrite the previous one. However, when I launch the updated app, it asks for Screen Recording permission again, even though I have already granted it for the previous version. I don’t fully understand how TCC (Transparency, Consent, and Control) determines when permissions need to be re-granted. Can anyone explain how TCC manages permissions for updated builds, especially with adhoc signatures? Is there any way to retain permissions between updates, or any best practices to avoid having users re-authorize permissions after every update?

There is no plus button ![](" https://developer.apple.com/kr/forums/content/attachment/4c286784-7329-4e31-a5b1-8dd0c9aaf9ad" "title=test.png;width=2330;height=982")

Note: This failure occurs even when running on the same machine that performed the build, signing, and notarization steps. We are developing a command-line Endpoint Security (ES) client for macOS, distributed to customers as part of an enterprise security suite. We have a valid Apple Developer Team ID (redacted for privacy) and have requested and received the Endpoint Security entitlement for our account. What We’ve Done Built a universal (x86_64/arm64) CLI ES client using Xcode on macOS Sonoma. Signed with a Developer ID Application certificate (matching our Team ID). Applied the entitlement: com.apple.developer.endpoint-security.client. Notarized the binary via notarytool after receiving Apple’s confirmation that the entitlement was “assigned to our account.” Distributed and unzipped the notarized ZIP (with com.apple.quarantine xattr intact). What Happens: When we run the binary (as root, via sudo) on any test Mac—including the original build/notarization machine—the process is killed immediately at launch. Kernel log (log stream --predicate 'eventMessage CONTAINS "AMFI"' --info) shows: AMFI: code signature validation failed. AMFI: bailing out because of restricted entitlements. AMFI: When validating /path/to/fidelisevents: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: What We’ve Verified: codesign -dvvv --entitlements :- ./fidelisevents shows the correct entitlement, team identifier, and certificate. xattr ./fidelisevents shows both com.apple.provenance and com.apple.quarantine. spctl -a -vv ./fidelisevents returns: rejected (the code is valid but does not seem to be an app) origin=Developer ID Application: [REDACTED] The process is killed even if run on the same Mac where build/sign/notarization occurred. Other Details The entitlement approval email from Apple simply says it is “assigned to your account” and does not mention “production” or “distribution.” We have rebuilt, re-signed, and re-notarized after receiving the email. This occurs on both Apple Silicon and Intel Macs, with recent macOS versions (Sonoma, Ventura). Question Is it possible that Apple only assigned the development Endpoint Security entitlement, and not the production entitlement required for distributing/running notarized ES clients outside of development? Is there any way to verify the level of entitlement (dev vs. production) associated with our Team ID? What additional steps, if any, are needed to enable the production entitlement so that our binaries can run on customer endpoints without being killed by AMFI? Any advice, experience, or official documentation about production ES entitlement rollout, approval, or troubleshooting would be greatly appreciated! Thanks in advance!

In some crashlog files, there are additional pieces of information related to codesigning. I can understand what most of themcorresponds to (ID, TeamID, Flags, Validation Category). But there is one I have some doubt about: Trust Level. As far as I can tell (or at least what Google and other search engines say), this is an unsigned 32 bit integer that defines the trust level with -1 being untrusted, 0, being basically an Apple executable and other potential bigger values corresponding to App Store binaries, Developer ID signature, etc. Yet, I'm not able to find a corresponding detailed documentation about this on Apple's developer website. I also had a look at the LightweightCodeRequirements "include" file and there does not seem to be such a field available. [Q] Is there any official documentation listing the different values for this trust level value and providing a clear description of what it corresponds to?

Hello, Trying to set this up so I can easily test on my mobile device through USB, I've got development mode setup, have my CSR (which i used for my dist profile and works perfectly). Logged into apple developer and have my organisation selected, when trying to create a dev certificate using the same CSR i used for dist, it seems like it just creates it under my name instead of my company, which would explain why, when i download and activate the dev cert, in xcode the dev certificate doesn't show, only the dist cert. If I create a dev profile using that cert it does load up in xcode, but when I select it I get this error: No signing certificate "iOS Development" found No "iOS Development" signing certificate matching team ID "{team_id}" with a private key was found. To me it seems like this is happening because the development certificate I created just decides to put itself not under my org, I thought this was just how it works for development certificates? Also when I do create the provisioning profile, I can select my company identifier and in the summary it does show my team id so really not sure what is going on. Would appreciate any guidance on this please.

Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

I encountered code signing issue with Apple Distribution certificate for both iOS and MacCatalyst. The app crashes with "Beta Profile". I followed this instruction to manually re-sign my ipa to confirm that I use the Apple Distribution and the correct Provisioning Profile. https://gist.github.com/WDUK/4239548f76bd77b2c4b0 When I double click on the Apple Distribution certificate in KeyChain Access, it shows "Extension: Apple Mac App Signing (Development)" and "Extension: Apple Developer Certificate (Submission)" I have been stuck in this issue for more than a month. I really need help because I do not know how to proceed further. Thank you.

Hello Engineers My app was rejected with the message below, BUT I don't have this entitlements in my project! I already removed all Xcode files under ${HOME}/Developer/Xcode, but the problem still alive! Guideline 2.4.5(i) - Performance In order to continue reviewing your app, we require additional information. Your app uses one or more entitlements which do not appear to have matching functionality within the app. Please reply to this message in App Store Connect and describe how and where the app uses the following entitlements. You will not need to upload a new binary to provide this information. Apps should have only the minimum set of entitlements necessary for the app to function properly. If there are entitlements that are not needed, please remove them and submit an updated binary. You will need to Developer Reject the app to upload an updated version. "com.apple.security.assets.pictures.read-write" "com.apple.security.assets.movies.read-write" "com.apple.security.assets.music.read-write" "com.apple.security.files.downloads.read-write" Here my entitlements: <?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.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.org.eof.apps</string> </array> <key>com.apple.security.files.user-selected.read-write</key> <true/> </dict> </plist> code-block Who or where are these entitlements inserted? Which button should be clicked to deactivate them? Link to my project: DRFXBuilder Regards

I'm currently developing a Unity game for iPad and have run into a critical issue that's completely blocking me from building the project. The project uses the Mapbox SDK for Unity. Everything was working fine during today test build on the iPad. I made minor changes - just four scripts, then attempted another build. However, Xcode began showing the following error: The signature of “MapboxCommon.xcframework” cannot be validated and may have been compromised. Validation Error: The signing certificate has been revoked (CSSMERR_TP_CERT_REVOKED) This error now occurs consistently. I've tried building on a different MacBook and with a different Apple account, but the result is the same. I haven't made any changes to the Mapbox framework, nor have I updated it recently. I'm trying to determine the root cause: Is this something I've done on my end? Or is it an issue with the Mapbox framework or their signing certificate? Is there a temporary workaround that would allow me to proceed with development builds while I investigate a proper fix? Any insights or suggestions would be greatly appreciated.

Hi, I am using Xcode 16.4, and my test device is Iphone 16 pro max. Everything was working fine until today when I get an error that I cannot install the app on the device. The error I get is: Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.cRjyg7/extracted/[myapp].app : 0xe8008015 (A valid provisioning profile for this executable was not found.) Please ensure sure that your app is signed by a valid provisioning profile. Creating a new project and installing it to the mobile works fine. Please can someone from Apple or the community respond? there are many posts with this error but none were solved. Troubleshooting attempts included: Resetting all certificates. delete the app from the device unpairing device codesigning via cli reloading older git code commit Nothing is working. thanks

I spent 20 minutes trying to figure out why codesigning was failing -- I had the pf block set up correctly, my keychains were unlocked, and then, eventually, it occurred to me, hey, maybe an IP address changed, so I disabled IPv6 except for link local, and then amazingly, it went back to working. I filed FB13706261 over a year ago. This is ridiculous.

I am having an issue with signing and provisioning a Vision OS app. I have an iOS app and a VisionOS app. Everything works fine on the iOS but having issues with the VisionOS. First, I am having issues with xcodebuild -exportArchive. When I run it on an archive of my VisionOS app I get ** EXPORT FAILED ** error: exportArchive No Accounts error: exportArchive No profiles for 'X' were found Where X is my bundle ID. Meanwhile the iOS app succeeds. This is on a CI machine but I confirmed the distribution provision profile for the vision OS app is installed on the machine. Even if I change the value of the -exportOptionsPlist to the one I used for the iOS project I get this error. Is the issue in the archive itself? The archives are generated from building in Unity and archiving the xcodeproject with xcodebuild archive Second, as a workaround I archived a debug ipa on my machine and uploaded this ipa to my CI machine which has the credentials to sign for distribution. I use this script as an example as how to resign the IPA: https://gist.github.com/lodalo/754a35b48d382ae99b25 I remove the CodeSignatures and codesign both .app and UnityFramework.framework. Using this resigned IPA I get this error when I try to upload to app store connect (via Transporter app and altool) errors: Validation failed (409) Missing or invalid signature. The bundle 'X' at bundle path 'Payload/Y.app' is not signed using an Apple submission certificate. To verify the signing I used codesign -dvvv --entitlements - On both the iOS and VisionOS app and they have the same values under all the Authority fields. Different profiles, of course. So the certificate I used is eligible to upload the iOS app successfully but doesn't work on the VisionOS ipa? Any help on solving any of these issues would be great so I can upload the vision OS app. Thank you!

Hi everyone, After I recently changed my Apple ID (iCloud) password, my Developer ID certificate stopped working for signing macOS apps. Symptoms: Signing fails with the Developer ID certificate that was previously working fine. I tried re-downloading the certificate from my Apple Developer account and importing it into the Keychain, but the issue persists. It seems that the Developer ID identity is no longer trusted or properly linked to my system since the password change. Attempts: Re-downloaded and installed the certificate from the developer portal. Verified that the private key is present and linked. Checked keychain access and code-signing identity — everything appears normal, but the signed apps are rejected or the signing process fails. Blocking issue: I am unable to delete or revoke the Developer ID certificate on my account (Apple Support says it's not possible). Also, I can't create a new one due to the certificate limit. Questions: Is it expected for a Developer ID certificate to become invalid after changing the Apple ID password? Is there a recommended way to refresh or restore the certificate trust on macOS? How can I invalidate the current certificate and generate a new one if I'm stuck? Any insights or official guidance would be really appreciated. Thanks in advance!

In xcode, the signing&amp;capabilities TAB for ios says: Automatic signing failed Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator. Provisioning profile "iOS Team Provisioning Profile: com.kikk.morsecode" doesn't include the com.apple.developer.in-app-purchase entitlement. Even though I've already configured the corresponding Certificates, Identifiers &amp; Profiles in developer Does anyone have the same problem? My Version of xcode is Version 15.4 (15F31d), running on m2pro.