You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I am trying to notarize my first macOS app for direct distribution outside the Mac App Store using Developer ID Application signing. Team ID: 32S6XVAQPY Environment: macOS app distributed via Developer ID notarytool with a saved keychain profile archive exported locally, app zipped with ditto What I already verified locally: The archived app is signed with: Developer ID Application: (32S6XVAQPY) codesign --verify --deep --strict passes spctl shows: source=Unnotarized Developer ID syspolicy_check distribution only reports the expected missing notary ticket Hardened runtime is enabled The app bundle and nested Sparkle executables were re-signed and now have valid Developer ID signatures with secure timestamps Important note: I previously had a real signing issue in nested Sparkle binaries, and Apple rejected that submission quickly as Invalid. I fixed those signatures, and now new submissions no longer fail quickly but remain stuck In Progress. Submission IDs currently stuck: bea6c4b3-b107-4c81-8042-6c58b1cf5087 5489e29c-d583-4779-a125-ca0fbd9cad0b Earlier invalid submission with a concrete Sparkle signing error: 10df648b-eca8-428f-98d6-4cb4096153ad Apple reported invalid Developer ID / missing secure timestamp on: Sparkle.framework/Versions/B/Updater.app/Contents/MacOS/Updater Sparkle.framework/Versions/B/Autoupdate Sparkle.framework/Versions/B/XPCServices/Downloader.xpc/Contents/MacOS/Downloader Sparkle.framework/Versions/B/XPCServices/Installer.xpc/Contents/MacOS/Installer That Sparkle issue has since been fixed locally and re-verified. Question: Is there currently a notarization backlog or any known issue affecting first-time macOS notarizations or Developer ID submissions? At this point the remaining submissions appear valid locally but sit In Progress for a very long time.

All my notarization submissions are rejected with statusCode 7000 ("Team is not yet configured for notarization"), even though my Apple Developer Program membership has been active since February 26, 2026. Error log: status: Rejected statusCode: 7000 statusSummary: "Team is not yet configured for notarization" My setup: Team ID: 9NL8W3646T Membership: Individual, ACTIVE (confirmed by Apple Support on Feb 26) Certificate: Developer ID Application — valid, signing works Hardened runtime: enabled Latest failed submission: ce6a4ca9-ccc2-4838-b96a-d9ed16557237 (March 6) I have support case 102832266798 open since March 4. Apple responded on March 6, but the email never arrived in my inbox and the portal doesn't let me view the response. Could DTS help enable notarization for my team? This is blocking distribution of my macOS app. Thank you.

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

Apple has introduced the Wireless Insights Service Predictions capability in iOS 26. After prior alignment with Apple engineers, we are working to integrate this capability into the Douyin App, and intend to provide a TestFlight build for Apple engineers to validate and debug the integration. We have encountered a blocking issue with entitlement configuration: We use our Apple Developer Enterprise Program account to build and submit TestFlight builds. When we manually create and configure provisioning profiles via the Apple Developer Portal, the required entitlement key com.apple.developer.wireless-insights.service-predictions is not available for selection or inclusion in the profile's Entitlements. This completely blocks us from enabling, using, and validating the Wireless Insights Service Predictions capability. For comparison, when we use our Apple Developer Program individual account, the entitlement com.apple.developer.wireless-insights.service-predictions is fully available. It is automatically included in provisioning profiles generated for local debugging, and can also be manually added to custom provisioning profiles via the Apple Developer Portal without issues. We request assistance to resolve this entitlement access discrepancy for our Enterprise Program account, so that we can complete the integration and provide the TestFlight build for validation as planned.

Hi, I have two notarization submissions that have been stuck in "In Progress" status for several hours with no resolution. Submission IDs: 2158329b-8beb-400b-aa80-f8c2a5f30106 (submitted ~9 hours ago) 73174908-3ed9-4a85-afe0-a3c3b0722a61 (submitted ~3 hours ago) Both submissions show "In Progress" indefinitely and no log is available for either. The notarytool --wait --timeout 30m timed out on the second submission with exit code 124. The app is signed with a valid Developer ID Application certificate, all binaries including frameworks and dylibs are individually signed with --options runtime and --timestamp. A previous submission returned valid on disk / satisfies its Designated Requirement via spctl --assess. Could you please investigate whether these submissions are stuck on your end, and advise on next steps? Thank you.

I'm submitting my first macOS app (an Electron app, signed with Developer ID Application certificate and hardened runtime) for notarization using xcrun notarytool submit with App Store Connect API key authentication. All 6 of my submissions have been stuck at "In Progress" for over 24 hours now. The oldest submission is 27+ hours old. None have transitioned to Accepted or Invalid. Here's what I've verified: Code signing is valid: codesign --verify --deep --strict passes Hardened runtime is enabled Uploads succeed: Each submission receives a valid submission ID and the file uploads successfully to Apple's servers API key auth is working: Using App Store Connect API key (.p8 file), Key ID, and Issuer ID Tried both locally and via GitHub Actions CI — same result Polling Apple's status endpoint eventually times out with NSURLErrorDomain Code=-1001 "The request timed out" when checking https://appstoreconnect.apple.com/notary/v2/submissions/<id> Logs are not available (notarytool log returns "not yet available" for all submissions) Apple Developer System Status shows "Developer ID Notary Service" as Available Submission history: createdDate: 2026-02-04T20:27:16Z — status: In Progress createdDate: 2026-02-04T16:45:18Z — status: In Progress createdDate: 2026-02-04T13:40:23Z — status: In Progress createdDate: 2026-02-04T12:29:52Z — status: In Progress createdDate: 2026-02-04T11:26:36Z — status: In Progress createdDate: 2026-02-04T11:21:39Z — status: In Progress Entitlements used: com.apple.security.cs.allow-jit com.apple.security.cs.allow-unsigned-executable-memory com.apple.security.cs.disable-library-validation com.apple.security.network.client com.apple.security.files.user-selected.read-write This is my first time notarizing any app on this developer account. I've seen other threads mentioning that first-time submissions can be "held for in-depth analysis," but 24+ hours with no feedback at all seems excessive. Is anyone else currently experiencing this? Is there anything I can do to unblock my account's notarization queue, or do I just need to wait? Any guidance from DTS would be greatly appreciated. I've also emailed Apple Developer Support but haven't received a response yet.

Hello We have a pkg installer whose signing certificate is expiring next month. It has a trusted timestamp on it. As per https://developer.apple.com/support/certificates/ it states Developer ID Installer Certificate (Mac applications) If your certificate expires, users can still install packages that were signed with this certificate as long as the package includes a trusted timestamp. Previously installed apps will continue to run. However, new installations won’t be possible until you have re-signed your installer package with a valid Developer ID Installer certificate. If your certificate is revoked, users will no longer be able to install applications that have been signed with this certificate. Wanted to check on behavior for new installations post expiration date. Since the installer has a trusted timestamp we would not need to release a new installer with new cert ?? Any guidance here would be much appreciated.

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 a number of different 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. UUID This is a standard universally unique identifier. For example, the App Store Connect API key associated with this post has a issuer UUID of c055ca8c-e5a8-4836-b61d-aa5794eeb3f4. Email or phone See the Apple Account section below for more on this. Decimal number This is a simple decimal number. For example, the Apple ID for Apple Configurator is 1037126344. 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 Managed capability request ID | 10-character | `M79GVA97FK` | Identifies a request for a managed capability App Store Connect API key ID | 10-character | `T9GPZ92M7K` | Identifies a key used for App Store Connect API authentication App Store Connect API issuer | UUID | `c055ca8c-e5a8-4836-b61d-aa5794eeb3f4` | Identifies a key issuer in the App Store Connect API Apple Account | email or phone | `user@example.com` | Identifies a user to the Developer website and App Store Connect Apple ID | decimal number | 1037126344 | Identifies an app in App Store Connect 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. Managed Capability Request ID Managed capabilities must be assigned to your account by Apple before you can use them. You apply for these using the Capability Requests tab on the Developer website. For more details, see New Capabilities Request Tab in Certificates, Identifiers & Profiles. When you make such a request, the Developer website assigns it a request ID, using the 10-character format. For example, M79GVA97FK is the request ID for an Apple test request. These request IDs are purely administrative; they have no build-time or run-time impact. App Store Connect API Keys The App Store Connect API authenticates requests using API keys. For the details, see Creating API Keys for App Store Connect API. Each API key has an associated issuer and key ID. The issuer is a UUID, for example, c055ca8c-e5a8-4836-b61d-aa5794eeb3f4. The key ID uses the 10-character format, for example, T9GPZ92M7K. These identifiers have no run-time impact, but they might be relevant when you’re building your app. For example: If your continuous integration (CI) uses the App Store Connect API, it will need an API key and its associated identifiers. If you notarise a Mac product, you might choose to authenticate using an App Store Connect API key and its associated identifiers. For an example of how to do that with notarytool, see TN3147 Migrating to the latest notarization tool. Apple Account An Apple Account is the personal account you use to access Apple services, including the Developer website and App Store Connect. Historically this was an email address, but nowadays you can also use a phone number. For more about Apple Accounts, see the Apple Account website. Your Apple Account was previously know as your Apple ID, which was confusingly similar to the next identifier. Apple ID In App Store Connect, an Apple ID refers to a decimal number that identifies your app. For example, the Apple ID for Apple Configurator is 1037126344. To see this in App Store Connect, navigate to the app record, select App Information on the left, and look for the Apple ID field. It’s a decimal number, usually around 10 digits long. You can also find this embedded in the App Store URL for the app. For example, the Apple Store URL for Apple Configurator is https://apps.apple.com/us/app/apple-configurator-2/id1037126344, which ends with its Apple ID. Note In some very obscure cases you might see this referred to as an Adam ID. Your app’s Apple ID is not used at runtime, but you may need to know it to accomplish administrative tasks. For example, most managed capability submission forms ask for your app’s Apple ID. Revision History 2026-03-05 Added the Apple Account and Apple ID sections. 2026-02-25 Added the Managed Capability Request ID and App Store Connect API Keys sections. Added UUID to the list of format. 2026-02-17 Corrected a minor formatting problem. 2026-01-06 First posted.

I have gotten all necessary entitlements for all my extensions,

I requested the Family Controls (distribution) capability but am not sure if I did it correct. I applied, answered the questions why i needed it and submitted. Its been about 2 weeks since applying. In the app configurations, it on apple dev site, it shows in the request history that I submitted it on March 17, but I can click the request (+) button and request it again. Just want to make sure I didn't mess anything up--it seems like they would prevent me from sendin another request if I had already requested it. It hasn't taken them this long to get back to me in the past which is why I am confused. If anyone knows how to speed up the process, please let me know! Thanks.

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

Your development team has reached the maximum number of registered iPhone devices. I am use the free provisioning file. So how can I delete old device and use my new iPhone to develop my app. only way is use a paid account? or register a new Apple ID?

Context: I am building an iOS productivity app using EAS Build. The project has 4 targets: the main app and 3 extensions (ShieldAction, ShieldConfiguration, ActivityMonitorExtension). The Issue: I have officially received approval from Apple for the Family Controls (Distribution) entitlement for my main Bundle ID. However, the build still fails during the Xcode phase. The Errors: Xcode reports that the generated provisioning profiles do not include the com.apple.developer.family-controls entitlement. For example: Provisioning profile "*[expo] com.*.** AdHoc 177247892...." doesn't support the Family Controls capability. All 3 extensions are failing with the exact same error. What I've done: Confirmed approval from Apple for com.*.**. Enabled Family Controls and App Groups on the Apple Developer Portal for all 4 Identifiers. Cleared EAS local and remote cache using eas build --clear-cache. Deleted existing profiles on both Expo.dev and Apple Portal to force regeneration. The Question: Even with official approval, why does EAS continue to generate "empty" profiles for my Ad-Hoc development build? Do I need separate approval for each extension's Bundle ID, or is there a way to force EAS to sync these "Managed Capabilities" correctly?

the iOS app store package's entitlements file has an issue. After updating to a new version to fix the entitlements file, the app still crashes upon opening but can function normally after a restart. What methods can the app side use to resolve this entitlements file issue without requiring a restart to open and use the app properly?

I'm submitting a native macOS app (Swift/SwiftUI, arm64) that includes Sparkle.framework for auto-updates. All binaries are signed with a Developer ID Application certificate using --options runtime and --timestamp. I've submitted 12+ times over the past two days, both from local notarytool submit and from GitHub Actions CI. Every submission uploads successfully and returns a valid submission ID, but then stays at "In Progress" indefinitely — none have resolved to Accepted or Invalid. Two early submissions did eventually come back "Invalid" — Apple's rejection log showed the Sparkle nested binaries had ad-hoc signatures (they were being signed as individual Mach-O files instead of bundle directories). I fixed this with proper inside-out bundle signing. Since the fix, local codesign --verify --deep --strict passes cleanly, but all ~10 subsequent submissions remain stuck at "In Progress". 9UT54V24XG Would appreciate any guidance, or if someone from the notary team could check our queue. Happy to provide specific submission IDs.

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

I've seen a few posts about this online and it seems that Xcode generates random team ID's with it's automatic signing system. But I haven't seen any way to make this work properly. If I log into the dev portal and look at my account, in the upper right I can see my team ID. If I manually generate a cert, I get a totally different one. Question: How can I generate a cert with my proper team ID (my paid account) where the ID's on my certs, identifiers and profiles all match? I've never had this issue before and am unsure how to solve it.

We've got an in-house Swift macOS desktop app with a FileProvider extension, which has been working fine on various machines up through Sonoma (and still does). We've just installed it on a Sequoia machine, and on it the FileProvider extension has lost the ability to access the shared app group. It can neither log to the Group Containers folder under ~/Library, nor access the pipe to the main app. The group name is formatted as group.XXXXXXXXXX.com.orgname.appname in both targets. I'm not sure why it combines the iOS and macOS conventions, with both the group prefix and the teamIdentifier one -- it was first built some time before the point in 2025 when macOS supported iOS-style groups -- but again, it's been working. For the record, The provisioning profile for EMPFileProvider has the App Groups capability enabled, and the App Groups capability is present in both build targets in Xcode. The existing group identifier is registered on the website; I've also manually registered the team-ID-less group name, so I can migrate. The question is, is this actually the right approach? Will such a change break the app on pre-Sequoia machines? And if I proceed, what do I need to do to complete the migration? The app was built back in Xcode 12.5; will I need to update the entire build environment to take advantage of Xcode 16.3's explicit support for iOS-style group names, or can I get away with it since I've manually registered the new group?