I will post my app xyz.app uses XY swift package this swift package is a wrapper for XYSDK.xcframework XYSDK.xcframework written in c++ and app running on arm64 macos and iphones succesfully. I got this error when i want to distribute it. Currently i sign .framework for ios with Apple Distribution Certificate and same certificate for macos framework there is no other signing step for swift package or xcframework other than that when i want to archive it validates succesfully. Exporting step shows that app has signed, has provisining profile. but .framework is only signed has no provisioning profile. Also one point i see: i have one target named xyz and its Frameworks, Lİbraries and Embedded Context has only XY package but Embed part has no option like embed and sign etc. Blank. I need more info about what am i doing wrong in which step ? I am stuck and can not move any further like weeks Error Detail: Invalid Signature. The binary with bundle identifier XYSDK at path “xyz.app/Frameworks/XYSDK.framework” contains an invalid signature. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. (90035)

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?

Hi, we are sending MacOS apps packaged in a ZIP archive or DMG disk image to the Notary Service. Before we send the app for notarization, we check the code signature via command codesign -vvv --deep --strict /path/to/app_or_bundle The result is positive and it does not provide any gaps. (And yes, we are following the inside out code signing approach, mentioned at Using the codesign Tool's --deep Option Correctly) Unfortunately, the result of the Notary service provided that one file has no signature, which was not detected by the signature verification command. The path of the binary was in <app_name>.app.zip/<app_name>.app/Contents/Resources/inst/<binary> How I can be verify like a the Notary service does it on our side? Best regards, Stefan

I want to help contribute a feature in a virtual-machine app in macOS that supports PCIe device passthrough over thunderbolt. I have a question about the entitlements. Since I do not represent the GPU vendors, would I be allowed to get a driver signed that matches GPU vendor IDs? Is there such a thing as wildcard entitlement for PCIDriverKit? I don't want end-users to have to disable SIP to be able to use this. Any suggestions/leads? Thank you.

Hi All, Really weird one here... I have two bundle ids with the same reverse dns name... com.company.app1 com.company.app2 app1 was installed on the device a year ago. app2 was also installed on the device a year ago but I released a new updated version and pushed it to the device via Microsoft InTunes. A year ago the vendor Id's matched as the bundle id's were on the same domain of com.company. Now for some reason the new build of app2 or any new app I build isn't being recognised as on the same domain as app1 even though the bundle id should make it so and so the Vendor Id's do not match and it is causing me major problems as I rely on the Vendor Id to exchange data between the apps on a certain device. In an enterprise environment, does anyone know of any other reason or things that could affect the Vendor Id? According to Apple docs, it seems that only the bundle name affects the vendor id but it isn't following those rules in this instance.

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

Multiple notarization submissions have been stuck at "In Progress" status for over 2 days with no resolution or error: 4996643b-4512-4025-9648-028fbafca82f - submitted Jan 18 b6db6cd0-dad7-4a8e-b1fc-379467c1086d - submitted Jan 17 88f269c1-56ea-4404-98ba-edbe9a05b3d2 - submitted Jan 19 No logs available (notarytool log returns "not yet available"). The submissions were uploaded successfully and received submission IDs. Is there a known issue with the notarization service?

Hello everyone, I’m trying to notarize my macOS app (DockIt.zip) using the new notarytool CLI, but every submission remains in In Progress status forever, it never moves to Accepted or Rejected. I’ve tried multiple rebuilds, credential resets, and even the Xcode GUI method, but the result is the same. Environment • macOS 14.x • Xcode 15.x / Command-Line Tools 15.x • Apple ID: afonsocruz.dev@icloud.com (Team ID: 264Z9XKCT6) • Keychain profile: DockItCreds Steps taken 1. zip -r DockIt.zip DockIt.app 2. xcrun notarytool store-credentials DockItCreds --apple-id ... --team-id 264Z9XKCT6 3. xcrun notarytool submit DockIt.zip --keychain-profile DockItCreds --wait 4. xcrun notarytool history --keychain-profile DockItCreds History snapshot 167a9600-5c7c-4bc4-b984-dd967d30e161 (2025-05-19T11:37:59Z) – In Progress 7167f7c8-d448-4b35-9817-055009f2730a (2025-05-19T04:59:34Z) – In Progress 6ef0610a-595f-4c57-b0f2-f5fe783e8679 (2025-05-18T22:04:10Z) – In Progress bddde388-a34a-42c4-afb8-f06f2b0fe8fa (2025-05-17T10:24:07Z) – In Progress Questions Is it normal to stay “In Progress” for so long? Any recent service changes or outages? How can I get more detailed logs? Also, I'm still learning about macOS development and these steps! If there's something obvious and I was not able to see, please, take into consideration! Thanks!

I added a new device and it's not recognizing the device model. This causes a message saying "Unable to verify" when signing an app. Has anyone else encountered this issue? This only happens with this one device, not others.

Error in application:didFailToRegisterForRemoteNotificationsWithError: no valid aps-environment entitlement string found for application have tried out the below commands % codesign -d --entitlements - /path/to/your.app % security cms -D -i /path/to/your.app/embedded.mobileprovision and it seems both are working fine, Im currently developing react native app with expo and firebase for notifications this works fine when im running it via installing the app from testflight, but the issue occurs when i test in testflight or while the apple team reviewing my app My entitlements file <dict> <key>aps-environment</key> <string>production</string> </dict> </plist>

Code signing uses various different identifier types, and I’ve seen a lot of folks confused as to which is which. This post is my attempt to clear up that confusion. If you have questions or comments, put them in a new thread, using the same topic area and tags as this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Code Signing Identifiers Explained An identifier is a short string that uniquely identifies a resource. Apple’s code-signing infrastructure uses identifiers for various different resource types. These identifiers typically use one of a small selection of formats, so it’s not always clear what type of identifier you’re looking at. This post lists the common identifiers used by code signing, shows the expected format, and gives references to further reading. Unless otherwise noted, any information about iOS applies to iOS, iPadOS, tvOS, visionOS, and watchOS. Formats The code-signing identifiers discussed here use one of two formats: 10-character This is composed of 10 ASCII characters. For example, Team IDs use this format, as illustrated by the Team ID of one of Apple’s test teams: Z7P62XVNWC. Reverse-DNS This is composed of labels separated by a dot. For example, bundle IDs use this format, as illustrated by the bundle ID of the test app associated with this post: com.example.tn3NNNapp. The Domain Name System has strict rules about domain names, in terms of overall length, label length, text encoding, and case sensitivity. The reverse-DNS identifiers used by code signing may or may not have similar limits. When in doubt, consult the documentation for the specific identifier type. Reverse-DNS names are just a convenient way to format a string. You don’t have to control the corresponding DNS name. You can, for example, use com.<SomeCompany>.my-app as your bundle ID regardless of whether you control the <SomeCompany>.com domain name. To securely associate your app with a domain, use associated domains. For more on that, see Supporting associated domains. IMPORTANT Don’t use com.apple. in your reverse-DNS identifiers. That can yield unexpected results. Identifiers The following table summarises the identifiers covered below: Name | Format | Example | Notes ---- | ------ | ------- | ----- Team ID | 10-character | `Z7P62XVNWC` | Identifies a developer team User ID | 10-character | `UT376R4K29` | Identifies a developer Team Member ID | 10-character | `EW7W773AA7` | Identifies a developer in a team Bundle ID | reverse-DNS | `com.example.tn3NNNapp` | Identifies an app App ID prefix | 10-character | `Z7P62XVNWC` | Part of an App ID | | `VYRRC68ZE6` | App ID | mixed | `Z7P62XVNWC.com.example.tn3NNNNapp` | Connects an app and its provisioning profile | | `VYRRC68ZE6.com.example.tn3NNNNappB` | Code-signing identifier | reverse-DNS | `com.example.tn3NNNapp` | Identifies code to macOS | | `tn3NNNtool` | App group ID | reverse DNS | `group.tn3NNNapp.shared` | Identifies an app group | reverse DNS | `Z7P62XVNWC.tn3NNNapp.shared` | Identifies an macOS-style app group As you can see, there’s no clear way to distinguish a Team ID, User ID, Team Member ID, and an App ID prefix. You have to determine that based on the context. In contrast, you choose your own bundle ID and app group ID values, so choose values that make it easier to keep things straight. Team ID When you set up a team on the Developer website, it generates a unique Team ID for that team. This uses the 10-character format. For example, Z7P62XVNWC is the Team ID for an Apple test team. When the Developer website issues a certificate to a team, or a user within a team, it sets the Subject Name > Organisational Unit field to the Team ID. When the Developer website issues a certificate to a team, as opposed to a user in that team, it embeds the Team ID in the Subject > Common Name field. For example, a Developer ID Application certificate for the Team ID Z7P62XVNWC has the name Developer ID Application: <TeamName> (Z7P62XVNWC). ### User ID When you first sign in to the Developer website, it generates a unique User ID for your Apple Account. This User ID uses the 10-character format. For example, UT376R4K29 is the User ID for an Apple test user. When the Developer website issues a certificate to a user, it sets the Subject Name > User ID field to that user’s User ID. It uses the same value for that user in all teams. Team Member ID When you join a team on the Developer website, it generates a unique Team Member ID to track your association with that team. This uses the 10-character format. For example, EW7W773AA7 is the Team Member ID for User ID UT376R4K29 in Team ID Z7P62XVNWC. When the Developer website issues a certificate to a user on a team, it embeds the Team Member ID in the Subject > Common Name field. For example, an Apple Development certificate for User ID UT376R4K29 on Team ID Z7P62XVNWC has the name Apple Development: <UserName> (EW7W773AA7). IMPORTANT This naming system is a common source of confusion. Developers see this ID and wonder why it doesn’t match their Team ID. The advantage of this naming scheme is that each certificate gets a unique name even if the team has multiple members with the same name. The John Smiths of this world appreciate this very much. Bundle ID A bundle ID is a reverse-DNS identifier that identifies a single app throughout Apple’s ecosystem. For example, the test app associated with this post has a bundle ID of com.example.tn3NNNapp. If two apps have the same bundle ID, they are considered to be the same app. Bundle IDs have strict limits on their format. For the details, see CFBundleIdentifier. If your macOS code consumes bundle IDs — for example, you’re creating a security product that checks the identity of code — be warned that not all bundle IDs conform to the documented format. And non-bundled code, like a command-line tool or dynamic library, typically doesn’t have a bundle ID. Moreover, malicious code might use arbitrary bytes as the bundle ID, bytes that don’t parse as either ASCII or UTF-8. WARNING On macOS, don’t assume that a bundle ID follows the documented format, is UTF-8, or is even text at all. Do not assume that a bundle ID that starts with com.apple. represents Apple code. A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements. On iOS this isn’t a problem because the Developer website checks the bundle ID format when you register your App ID. App ID prefix An App ID prefix forms part of an App ID (see below). It’s a 10-character identifier that’s either: The Team ID of the app’s team A unique App ID prefix Note Historically a unique App ID prefix was called a Bundle Seed ID. A unique App ID prefix is a 10-character identifier generated by Apple and allocated to your team, different from your Team ID. For example, Team ID Z7P62XVNWC has been allocated the unique App ID prefix of VYRRC68ZE6. Unique App ID prefixes are effectively deprecated: You can’t create a new App ID prefix. So, unless your team is very old, you don’t have to worry about unique App ID prefixes at all. If a unique App ID prefix is available to your team, it’s possible to create a new App ID with that prefix. But doing so prevents that app from sharing state with other apps from your team. Unique app ID prefixes are not supported on macOS. If your app uses a unique App ID prefix, you can request that it be migrated to use your Team ID by contacting Apple > Developer > Contact Us. If you app has embedded app extensions that also use your unique App ID prefix, include all those App IDs in your migration request. WARNING Before migrating from a unique App ID prefix, read App ID Prefix Change and Keychain Access. App ID An App ID ties your app to its provisioning profile. Specifically: You allocate an App ID on the Developer website. You sign your app with an entitlement that claims your App ID. When you launch the app, the system looks for a profile that authorises that claim. App IDs are critical on iOS. On macOS, App IDs are only necessary when your app claims a restricted entitlement. See TN3125 Inside Code Signing: Provisioning Profiles for more about this. App IDs have the format <Prefix>.<BundleOrWildcard>, where: <Prefix> is the App ID prefix, discussed above. <BundleOrWildcard> is either a bundle ID, for an explicit App ID, or a wildcard, for a wildcard App ID. The wildcard follows bundle ID conventions except that it must end with a star (*). For example: Z7P62XVNWC.com.example.tn3NNNNapp is an explicit App ID for Team ID Z7P62XVNWC. Z7P62XVNWC.com.example.* is a wildcard App ID for Team ID Z7P62XVNWC. VYRRC68ZE6.com.example.tn3NNNNappB is an explicit App ID with the unique App ID prefix of VYRRC68ZE6. Provisioning profiles created for an explicit App ID authorise the claim of just that App ID. Provisioning profiles created for a wildcard App ID authorise the claim of any App IDs whose bundle ID matches the wildcard, where the star (*) matches zero or more arbitrary characters. Wildcard App IDs are helpful for quick tests. Most production apps claim an explicit App ID, because various features rely on that. For example, in-app purchase requires an explicit App ID. Code-signing identifier A code-signing identifier is a string chosen by the code’s signer to uniquely identify their code. IMPORTANT Don’t confuse this with a code-signing identity, which is a digital identity used for code signing. For more about code-signing identities, see TN3161 Inside Code Signing: Certificates. Code-signing identifiers exist on iOS but they don’t do anything useful. On iOS, all third-party code must be bundled, and the system ensures that the code’s code-signing identifier matches its bundle ID. On macOS, code-signing identifiers play an important role in code-signing requirements. For more on that topic, see TN3127 Inside Code Signing: Requirements. When signing code, see Creating distribution-signed code for macOS for advice on how to select a code-signing identifier. If your macOS code consumes code-signing identifiers — for example, you’re creating a security product that checks the identity of code — be warned that these identifiers look like bundle IDs but they are not the same as bundle IDs. While bundled code typically uses the bundled ID as the code-signing identifier, macOS doesn’t enforce that convention. And non-bundled code, like a command-line tool or dynamic library, often uses the file name as the code-signing identifier. Moreover, malicious code might use arbitrary bytes as the code-signing identifier, bytes that don’t parse as either ASCII or UTF-8. WARNING On macOS, don’t assume that a code-signing identifier is a well-formed bundle ID, UTF-8, or even text at all. Don’t assume that a code-signing identifier that starts with com.apple. represents Apple code. A better way to identify code on macOS is with its designated requirement, as explained in TN3127 Inside Code Signing: Requirements. App Group ID An app group ID identifies an app group, that is, a mechanism to share state between multiple apps from the same team. For more about app groups, see App Groups Entitlement and App Groups: macOS vs iOS: Working Towards Harmony. App group IDs use two different forms of reverse-DNS identifiers: iOS-style This has the format group.<GroupName>, for example, group.tn3NNNapp.shared. macOS-style This has the format <TeamID>.<GroupName>, for example, Z7P62XVNWC.tn3NNNapp.shared. The first form originated on iOS but is now supported on macOS as well. The second form is only supported on macOS. iOS-style app group IDs must be registered with the Developer website. That ensures that the ID is unique and that the <GroupName> follows bundle ID rules. macOS-style app group IDs are less constrained. When choosing such a macOS-style app group ID, follow bundle ID rules for the group name. If your macOS code consumes app group IDs, be warned that not all macOS-style app group IDs follow bundle ID format. Indeed, malicious code might use arbitrary bytes as the app group ID, bytes that don’t parse as either ASCII or UTF-8. WARNING Don’t assume that a macOS-style app group ID follows bundle ID rules, is UTF-8, or is even text at all. Don’t assume that a macOS-style app group ID where the group name starts with com.apple. represents Apple in any way. Some developers use app group IDs of the form <TeamID>.group.<GroupName>. There’s nothing special about this format. It’s just a macOS-style app group ID where the first label in the group name just happens to be group Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS. If you’re writing new code that uses app groups, use an iOS-style app group ID. This allows sharing between different product types, for example, between a native macOS app and an iOS app running on the Mac. Revision History 2026-01-06 First posted.

I'm developing an app that receives push notifications, and writes the contents of the push notification to a shared location between the main app and a Notifications Message Extension, through App Groups. This all seems to work on my phone, with developer mode turned on, but when I archive my app as an Enterprise IPA and distribute it, the users can install the app on their phones and they receive the push notifications, but it doesn't appear that the message extension is running as my app displays the content of the shared data in the App Groups on the main screen and nothing is showing. I have tried on 3 phones, and it only works on the phone with developer mode turned on. I can't tell at this point whether it's because of a signing issue, or build phase order issue, or something else?

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

App Notarization got stuck, showing In-Progress from last 24 hrs. This is really frustrating. Can anyone plz update on this?

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] Xcode 26.2, currently being seeded as Release Candidate, is much better about this (r. 155327166). Give it a whirl! Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.in-app-purchase.non-consumable — Likewise. com.apple.developer.in-app-purchase.subscription — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. com.apple.developer.musickit — There is no MusicKit capability. Rather, enable MusicKit via the App Services column in the App ID editor, accessible from Developer > Certificates, Identifiers, and Profiles > Identifiers. com.apple.mail.extension — Creating an app extension based on the MailKit framework does not require any specific entitlement. com.apple.security.accessibility — There’s no entitlement that gates access to the Accessibility APIs on macOS. Rather, this is controlled by the user in System Settings > Privacy & Security. Note that sandboxed apps can’t use these APIs. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. com.apple.developer.adservices — Using the AdServices framework does not require any specific entitlement. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2025-12-09 Updated the Xcode footnote to mention the improvements in Xcode 26.2rc. 2025-11-03 Added com.apple.developer.adservices to the common hallucinations list. 2025-10-30 Added com.apple.security.accessibility to the common hallucinations list. 2025-10-22 Added com.apple.mail.extension to the common hallucinations list. Also added two new in-app purchase hallucinations. 2025-09-26 Added com.apple.developer.musickit to the common hallucinations list. 2025-09-22 Added com.apple.developer.storekit to the common hallucinations list. 2025-09-05 Added com.apple.developer.device-activity to the common hallucinations list. 2025-09-02 First posted.

When I try to archive an app in order to submit it to the App Store I receive the following errors I do not know how to fix: error: Framework /Users/fbartolom/Library/Developer/Xcode/DerivedData/Virtual_Tags-apzduassdiglhcapscsllvzbfgid/Build/Intermediates.noindex/ArchiveIntermediates/Virtual Tags/InstallationBuildProductsLocation/Applications/VirtualTags.app/Frameworks/StoreKit.framework did not contain an Info.plist (in target 'VirtualTags' from project 'Virtual Tags') error: Framework /Users/fbartolom/Library/Developer/Xcode/DerivedData/Virtual_Tags-apzduassdiglhcapscsllvzbfgid/Build/Intermediates.noindex/ArchiveIntermediates/Virtual Tags/InstallationBuildProductsLocation/Applications/VirtualTags.app/Frameworks/Security.framework did not contain an Info.plist (in target 'VirtualTags' from project 'Virtual Tags') error: Framework /Users/fbartolom/Library/Developer/Xcode/DerivedData/Virtual_Tags-apzduassdiglhcapscsllvzbfgid/Build/Intermediates.noindex/ArchiveIntermediates/Virtual Tags/InstallationBuildProductsLocation/Applications/VirtualTags.app/Frameworks/CloudKit.framework did not contain an Info.plist (in target 'VirtualTags' from project 'Virtual Tags') MacBook Pro M5, Tahoe 26.1, Xcode 26.1.1

base" : 6481543168, "size" : 5134811136, "uuid" : "7bc5af5f-1e86-3b36-9036-16025c72cb70" }, "vmSummary" : "ReadOnly portion of Libraries: Total=1.0G resident=0K(0%) swapped_out_or_unallocated=1.0G(100%)\nWritable regions: Total=28.8M written=369K(1%) resident=369K(1%) swapped_out=0K(0%) unallocated=28.5M(99%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nAttributeGraph Data 1024K 1 \nCoreAnimation 48K 3 \nDispatch continuations 6144K 1 \nFoundation 16K 1 \nKernel Alloc Once 32K 1 \nMALLOC 16.8M 10 \nMALLOC guard page 3760K 4 \nSTACK GUARD 64K 4 \nStack 2640K 4 \n__AUTH 3975K 362 \n__AUTH_CONST 60.1M 643 \n__CTF 824 1 \n__DATA 28.6M 604 \n__DATA_CONST 24.9M 650 \n__DATA_DIRTY 4800K 581 \n__FONT_DATA 2352 1 \n__INFO_FILTER 8 1 \n__LINKEDIT 188.3M 7 \n__OBJC_RO 84.3M 1 \n__OBJC_RW 3177K 1 \n__TEXT 839.6M 666 \n__TPRO_CONST 128K 2 \nmapped file 32.7M 3 \npage table in kernel 369K 1 \nshared memory 80K 4 \n=========== ======= ======= \nTOTAL 1.3G 3558 \n", "legacyInfo" : { "threadTriggered" : { "queue" : "com.apple.main-thread" } }, "logWritingSignature" : "96bc482de9d7d2e828b9b488a2feab6193d3c188", "bug_type" : "309", "roots_installed" : 0, "trmStatus" : 1, "trialInfo" : { "rollouts" : [ ], "experiments" : [

Hi, At work, we've done some development on an Apple Vision Pro. On the project, we used object tracking to track an object in 3D and found the default tracking refresh rate (I believe 5Hz)to be too slow so we applied for enterprise APIs so we could change it. At some point, in the capabilities (as a beginner to Swift and the Apple development environment) I noticed that's where you enable the Object Tracking Parameter Adjustment API and I did so, before hearing back about whether we got access to the enterprise API's and the license file that comes with it. So I setup the re-fresh rate to 30Hz and logged the settings of the ObjectTrackingProvider, showing it was set at 30Hz and felt like it was better than the default when we ran our app. In the Xcode runtime logs, there was no warning or error saying that the license file for the enterprise API was not found (and I don't think we heard back from Apple if they had granted our request or not - even if they did I think the license would be expired by now). Fast forward to today, I was running the sample code of the Main Camera access for VisionOS linked in the official developer documentation and when I ran the project in Xcode, I noticed in the logs that it wanted an enterprise license and that's why it wasn't running as expected in the immersive space. We've since applied for the Enterprise API for Main Camera Access. I'm now confused - did I mistakenly believe the object tracking refresh rate was set to 30Hz but it actually wasn't due to the lack of a license file/being granted access to the enterprise APIs? It seemed to be running as expected without a license file. Is Object tracking Parameter Adjustment API handled with different permissions than Main Camera Access API even though they are both enterprise APIs? This is all for internal development and not planning on distributing an app but I find the behaviour to be confusing between the different enterprise API? Does anyone have more insight as I find the developer notes on the enterprise APIs to be a bit sparse.

Hi everyone, I’m having trouble getting remote push notifications working on iOS for a production Flutter app, and it looks like it’s related to the provisioning profile / entitlements used during signing. Context Platform: Flutter Push provider: OneSignal (backend is Supabase; Android push works fine) CI: Codemagic Target: iOS TestFlight / App Store builds I’m on Windows, so I cannot open Xcode locally. All iOS builds happen via Codemagic. Capabilities / entitlements In the Apple Developer portal, my App ID for com.zachspizza.app has: Push Notifications capability enabled A separate Broadcast capability is listed but currently not checked. In my repo, ios/Runner/Runner.entitlements contains: xml aps-environment production So the project is clearly requesting the push entitlement. Codemagic signing setup For my App Store workflow (ios_appstore_release in codemagic.yaml ): I use a combination of manual and automatic signing: Environment variables can provide: P12_BASE64 + P12_PASSWORD (distribution certificate) MOBILEPROVISION_BASE64 (a .mobileprovision file) A script in the workflow: Creates a temporary keychain. Imports the .p12 and installs the .mobileprovision into ~/Library/MobileDevice/Provisioning Profiles. For the final export, I generate an exportOptions.plist that does: If a profile name/UUID is provided via env (PROV_PROFILE_SPEC, PROV_PROFILE_UUID, PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE): xml signingStylemanual provisioningProfiles com.zachspizza.app[profile name or UUID] Otherwise, it falls back to: xml signingStyleautomatic After archiving and exporting, my script runs: bash codesign -d --entitlements :- "$ARCHIVE_PATH/Products/Applications/Runner.app" ... and again on the signed Runner.app inside the exported IPA codesign -d --entitlements :- "$SIGNED_APP" In both cases, the effective entitlements output does not show aps-environment, even though: The App ID has push enabled. Runner.entitlements includes aps-environment = production. Observed behavior iOS devices (TestFlight build) do not receive remote push notifications at all. Android devices receive notifications as expected with the same backend payloads. OneSignal configuration and backend are verified; this appears to be an APNs / signing / entitlements problem. The Codemagic logs strongly suggest that the provisioning profile being used for signing does not carry aps-environment. Questions Under what conditions would a distribution provisioning profile (for an App ID with Push Notifications enabled) result in a signed app without aps-environment, even when: The entitlements file in the project includes aps-environment, and The App ID in the Developer portal has Push Notifications enabled? Does using a CI flow like the above (custom .p12 + .mobileprovision installed via script, exportOptions with signingStyle=manual) increase the chances of: Xcode ignoring the requested entitlements, or Selecting a provisioning profile variant that does not include the push entitlement? Is there a recommended way, from the Apple side, to verify that a given .mobileprovision (the one I’m base64-encoding and installing in CI) definitely includes the aps-environment entitlement for my bundle ID? i.e., a canonical method to inspect the profile and confirm that APNs is included before using it in CI? Are there any known edge cases where: The project entitlements include aps-environment, The App ID has Push Notifications enabled, But the final signed app still has no aps-environment, due to profile mismatch or signing configuration? Given that I’m on Windows and can’t open Xcode to manage signing directly, I’d really appreciate guidance on how to ensure that the correct push-enabled provisioning profile is being used in this CI/manual-signing setup, and how to debug why aps-environment is being stripped or not applied. CodeMagic Signing/Export Step: Signing / entitlements output from Codemagic Dumping effective entitlements for Runner.app in archive... /Users/builder/clone/build/ios/archive/Runner.xcarchive/Products/Applications/Runner.app: code object is not signed at all Failed to dump entitlements Exporting IPA with exportOptions.plist... 2025-11-20 22:25:00.111 xcodebuild[4627:42054] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path "/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/Runner_2025-11-20_22-25-00.110.xcdistributionlogs". 2025-11-20 22:25:00.222 xcodebuild[4627:42054] [MT] IDEDistribution: Command line name "app-store" is deprecated. Use "app-store-connect" instead. ▸ Export Succeeded Dumping entitlements from signed Runner.app inside exported IPA... Executable=/private/var/folders/w2/rrf5p87d1bbfyphxc7jdnyvh0000gn/T/tmp.LHkTK7Zar0/Payload/Runner.app/Runner warning: Specifying ':' in the path is deprecated and will not work in a future release application-identifier.com.zachspizza.app beta-reports-active com.apple.developer.team-identifier get-task-allow As you can see, the signed app’s entitlements do not contain aps-environment at all, even though Runner.entitlements in the project has aps-environmentproduction and the App ID has Push Notifications enabled. Thanks in advance for any help and pointers.

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