The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command). There are three common symptoms of this problem: When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK. When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?. When displaying the code signature of a library, codesign prints this warning: % codesign -d vvv /path/to/your.dylib … Library validation warning=OS X SDK version before 10.9 does not support Library Validation … If you see any of these errors, read on… The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do? The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition. IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that’s not something you want to rely on in the long term. Heed this advice from About the Rosetta Translation Environment: Rosetta is meant to ease the transition to Apple silicon, giving you time to create a universal binary for your app. It is not a substitute for creating a native version of your app. But what about the short term? Historically I wasn’t able to offer any help on that front, but this has changed recently. Xcode 11 ships with a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime. Before doing this, consider these caveats: Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work. Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process. Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details. It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively. It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively. This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term. For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes. 2022-05-09 — Updated with a note about Apple silicon. 2020-09-11 — First posted.

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

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?

Hi All, I am building my own MDM server. It seems that in order for the MDM commands to function an MDM Push Certificate for the APNS framework. And in order to get the MDM Push Certificate from the Apple Push Certificates Portal (https://identity.apple.com/pushcert/) you need to upload your CSR usually provided and sign by the MDM Vendor of your choosing. I am familiar with this process. But now that I am the MDM Vendor, I am not sure where to get this MDM Vendor CSR Signing Certificate. I've already submitted a formal request via the "contact us" form. Apple's response pointed me to the documentation on Setting Up Push Notifications and the MDM Vendor CSR Signing Certificate help page (which I had already reviewed): https://developer.apple.com/documentation/devicemanagement/setting-up-push-notifications-for-your-mdm-customers https://developer.apple.com/help/account/certificates/mdm-vendor-csr-signing-certificate/ The issue is that these documents describe using the signing certificate, but not the process for obtaining it as a new, independent vendor. So does anyone know of a portal or method of generating this “MDM Vendor Certificate”? or maybe I'm going about this all wrong and there is a simpler way… the again, its apple, so I’m probably on the right path just beed a little direction please. (I am not sure where to get this MDM Vendor CSR Signing Certificate.)

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.

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?.

Hi, I'm currently at 19 hours waiting for notarization. My dev account is new and this is the first time I'm submitting anything to be notarized. I've gathered from my research that this is normal (unfortunately). I figure the only thing I can do is wait, but is there any way for me to know if I'm waiting for a human to manually review it? I was going to file a support request, but I saw that they won't be responding to any support requests until after their Thanksgiving break, and I assume nobody is manually reviewing notary submissions for the next week+. I attached the submission below, thanks! createdDate: 2025-11-21T21:17:10.082Z id: c9746d42-1dc7-4641-aec1-62c6cedff1a2 name: ***********.zip status: In Progress

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

Validation failed (409) Missing Code Signing Entitlements. No entitlements found in bundle 'com.seeyon.yiboyun.child' for executable 'Payload/M3.app/PlugIns/CMPSharePublish.appex/CMPSharePublish'." (ID: 6e5429ed-b896-45a0-ab23-bb8fcb472072)

I am trying to sign a enterprise app with provisioning profile which shows the tap to pay entitlement on Dev portal, but when downloaded on Xcode, it says the profile is missing the tap to pay capability and entitlement The capability was enabled by apple already, it was working fine until the provisioning profile got renewed.

I tried to create a new IOS provisioning profile and re-apply it to the app using Xcode to build it, but I got into trouble. The build is good, but it bounces when running the app. I would appreciate it if you could let me know what to do.

The capability associated with "FAMILY_CONTROLS" could not be determined. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator.

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

Hi All, Like many others I'm a little confused with gaining access to the family controls capability. Our app is ready to push to testflight, and we sent the request to apple last week. However only learning today that we need to request for the shield extension as well. I wanted to ask what the expected timeline is for being approved? I've seen posts here saying less than a week, and some people having to wait longer than 6 weeks. Any advise or guidance on getting approved smoothly & swiftly would be highly appreciated

I'm working on an app that needs access to device activity. When I add device activity entitlement, I'm getting Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. This is failing for both, the main app and the extension, and both have entitlements added. It is not clear how to add it to the profile, the provisioning profile is created/managed by XCode. When I remove the entitlement, I can build my app but it won't be able to use device activity data I reached out to Developer Support, and they sent me here. What is the right way to add device activity entitlement? I'm also seeing another issue with XCode Cloud builds. When I remove device activity entitlement. I can build my app w/o any issue, and I can also install it directly on my iPhone. However, XCode Cloud builds fail wit Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/d41fc2f1-4f39-4906-8941-112488e75f6c.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.68.193:8089' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' I suspect that it could be related to my app having DeviceActivityExtension but no device activity entitlement is present. Thanks, Peter.

i was complete my program, and export a mac app already it work ok in my macmini, but if i want send it to app store, that i have no way now i still do not know how to make this app perfect like, when i use pyinstaller to build this app, is there any info or elements need make with? i can sign my app now, even i use codesign -dvvv my.app to check the sign, it is also ok, there no any feedback said it anything wrong. so, any master know fix app sign or any infoplist please tech me... help

General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello, when building and signing my application in a Github actions workflow, I am facing an issue on the latest version of xCode (16.4). This issue is resolved by downgrading to 16.3. My CI/CD pipeline is running headless and installing provisioning profile to ~/Library/MobileDevice/Provisioning Profiles.

Hey, when I try to launch my app it prompts me with a "Apple could not verify" popup. The thing is the app has been signed and stapled. xcrun stapler validate .app for my app returns "The validate action worked!" If I also run syspolicy_check distribution .app it returns: "App passed all pre-distribution checks and is ready for distribution" Any idea?