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.

Hello, I'm experiencing a persistent issue where all my notarization submissions remain stuck in "In Progress" indefinitely. This has been happening for the past several days, affecting multiple submissions. Environment: macOS 26.2 (Build 25C56) Using xcrun notarytool submit for submissions Team ID: M3FN25UQK2 Timeline of the issue: Starting from January 2nd, 2026, my submissions began getting stuck in "In Progress" As of January 6th, I have 6+ submissions that have been "In Progress" for 24-72+ hours Prior to this, notarization was working normally (I have multiple "Accepted" submissions from January 1st) What I've tried: Verified my Developer ID Application certificate is valid and properly installed Checked Apple Developer System Status page (shows "Operational") Verified code signatures using codesign -vvv --deep --strict Contacted Apple Developer Support (no response yet) Checked my Apple Developer account for any pending agreements or warnings (none found) Is there any known issue affecting notarization processing, or could my Team ID be rate-limited/flagged? Any guidance on how to resolve this would be greatly appreciated. Thank you!

My iOS app was created with a legacy Team ID in 2011. When I try to add an AppClip to the app, the Team ID on the AppClip is the new Team ID. Xcode prevents the build from completing. The com.apple.developer.parent-application-identifiers entitlement (null) of an App Clip must match the application-identifier entitlement ('TYXXXXXP2.com.it-guy.MyApp') of its containing parent app. How can this be resolved? Can the AppClip Team ID be changed in "Identifiers" on the developer.apple.com?

Environment: MacBook Air Apple M2 (macOS Tahoe 26.1) Xcode 26.0 (17A324) Automatic signing enabled Feedback ID: FB21537761 Issue: I'm developing a multiplatform app and encountered an automatic signing failure immediately after adding the Keychain capability. Xcode displays the following error: Automatic signing failed Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator. Provisioning profile "Mac Team Provisioning Profile: com.xxx. xxx" doesn't include the currently selected device "FIRF‘s MacBook Air" (identifier 00008112-000904CA3441xxxx). What I've Investigated/Tried: Checked the developer account devices and found that the device with identifier 00008112-000904CA3441xxxx is incorrectly labeled as an “iPod” (it is actually my MacBook Air). Attempted to manually enroll the Mac again, but it still appears as an iPod in the device list. Tried creating a provisioning profile manually, but no devices are available for selection in the device list when generating the profile. Question: Has anyone encountered a similar issue where a Mac is misidentified as an iPod in the developer portal, leading to provisioning failures? Any suggestions on how to resolve this or work around the device recognition problem? Thank you in advance for your help.

Notarization Rejects Valid Developer ID Certificates - Apple Infrastructure Issue? Environment macOS: 15.6.1 Xcode: 26.0.1 Architecture: arm64 (Apple Silicon) Team ID: W---------- Certificate Status: Valid until 2030 (verified on developer.apple.com) Problem Apple's notarization service consistently rejected properly signed packages with error: "The binary is not signed with a valid Developer ID certificate." Despite: ✅ Valid certificates on developer.apple.com ✅ Local signing succeeds (codesign --verify passes) ✅ Proper certificate/key pairing verified ✅ Package structure correct Failed Submission IDs September 2025: adeeed3d-4732-49c6-a33c-724da43f9a4a 5a910f51-dc6d-4a5e-a1c7-b07f32376079 3930147e-daf6-4849-8b0a-26774fd92c3c b7fc8e4e-e03c-44e1-a68e-98b0db38aa39 d7dee4a1-68e8-44b5-85e9-05654425e044 da6fa563-ba21-4f9e-b677-80769bd23340 What I've Tried Re-downloaded fresh certificates from Apple Developer Portal Verified certificate chain locally Tested with multiple different builds Confirmed Team ID matches across all configurations Verified no unsigned nested components Waited 3 months for potential propagation delays Verified all agreements are current and accepted Re-tested with minimal test package - same error persists Local Verification # Certificates present and valid security find-identity -v -p codesigning | grep "Developer ID" 1) XXXXXXXXXX "Developer ID Application: <<REDACTED>> (W----------)" 2) XXXXXXXXXX "Developer ID Installer: <<REDACTED>> (W----------)" # Signing succeeds codesign --verify --deep --strict --verbose=2 [app] → Success Question This appears similar to thread #784184. After 3 months and ensuring all agreements are signed, the issue persists with identical error. The certificates work for local signing but Apple's notarization service rejects them. Could this be: Backend infrastructure issue with Team ID W----------? Certificate not properly registered in Apple's notarization database? Known issue requiring Apple Support intervention? Has anyone else experienced valid Developer ID certificates being rejected specifically by the notarization service while working locally?

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.

In an AppleScript applet, compiling and exporting in Script Editor replaces a custom icon with the default. To retain a custom icon, it is necessary, after exporting, to use Finder's "Get info..." to copy the icon from another file and paste into the icon for the applet. The custom icon is stored in the "Icon?" file, located in the root of the applet bundle. The applet can then be signed and notarized. With macOS Tahoe, that procedure no longer works. That is because the notarization process now wipes the "Icon?" file. The file remains in place but has zero size. Thus Finder shows the default applet icon. Does anyone know of a way to provide a custom icon for a signed and notarized AppleScript applet ?

The entire 'Certificates, IDs & Profiles' section is missing from developer.apple.com portal for one of the accounts I am a developer for. The Team is also missing from the dropdowns in Xcode in Code Signing. The organization account membership is paid through July 2026, and I do not see that the Account Holder needs to sign any agreements. I am a user on other accounts, and none of them have this issue. Does anyone know what's going on?

Hi everyone, I’m developing an Electron application on macOS and I’m trying to register and activate a macOS System Extension, but I’m running into startup and entitlement issues. 🔧 What I’m trying to build • An Electron app packaged with electron-builder • Signed with Developer ID Application • Notarized using @electron/notarize • A macOS System Extension is already built and signed • The System Extension provides a virtual camera • I wrote a Swift helper that: • Registers / activates the virtual camera • Calls OSSystemExtensionManager • This Swift code is compiled into a .node native addon • The .node module is loaded and called from Electron (Node.js) to trigger system extension registration ❗ The problem When I add the following entitlement: com.apple.developer.system-extension.install the application fails to launch at all on macOS. Without this entitlement: • The app launches normally • But system extension activation fails with: Error Domain=OSSystemExtensionErrorDomain Code=2 Missing entitlement com.apple.developer.system-extension.install With this entitlement: • The app does not launch • No UI is shown • macOS blocks execution silently 🤔 My questions 1. Is it valid for an Electron app’s main executable to have com.apple.developer.system-extension.install? 2. Does Apple require a separate helper / launcher app to install system extensions instead of the Electron main app? 3. Are there any Electron-specific limitations when working with macOS System Extensions? 4. Is there a known working example of Electron + macOS System Extension? 5. Do I need a specific provisioning profile or App ID capability beyond Developer ID + notarization?

I am trying to notarize a VS-Code Fork Electron based app for non-App store distribution. Its just same for more than 24hrs, it just says processing. Looking for someone who could help me. Thanks

We package a nightly build of our application for distribution. About 1 month ago, this package has started showing the "Apple could not verify 'Application' is free of malware" message. This only happens to our development branch package. We run the same pipeline with the same signature for our stable branch and the stable package does not show this message. $ codesign -dv --verbose=4 KiCad.app Executable=/Applications/KiCad/KiCad/KiCad.app/Contents/MacOS/kicad Identifier=org.kicad.kicad Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=51931 flags=0x10000(runtime) hashes=1612+7 location=embedded VersionPlatform=1 VersionMin=722432 VersionSDK=983552 Hash type=sha256 size=32 CandidateCDHash sha256=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d CandidateCDHashFull sha256=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d03cbe70641719fd1ced3395b Hash choices=sha256 CMSDigest=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d03cbe70641719fd1ced3395b CMSDigestType=2 Executable Segment base=0 Executable Segment limit=3915776 Executable Segment flags=0x1 Page size=4096 CDHash=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d Signature size=9002 Authority=Developer ID Application: KiCad Services Corporation (9FQDHNY6U2) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 19, 2025 at 5:21:05 AM Info.plist entries=17 TeamIdentifier=9FQDHNY6U2 Runtime Version=15.2.0 Sealed Resources version=2 rules=13 files=37238 Internal requirements count=1 size=176 codesign --verify --verbose=4 KiCad.app <snipped all libs validated> KiCad.app: valid on disk KiCad.app: satisfies its Designated Requirement % spctl --assess --verbose=4 KiCad.app KiCad.app: accepted source=Notarized Developer ID We distribute this via dmg. The notarization ticket is stapled to the dmg and the dmg opens without warning. Any help would be appreciated

Hey Apple Friends, We currently have an enterprise version of our app for debugging and internal distribution. Our release configuration uses our App Store account. However, it appears you cannot add a 'Declared Age Range' to the Enterprise app as a capability making it impossible to debug because we have added the 'Declared Age Range API' locally, but we cannot add it as a capability on the dev portal. Is there any work around for this?

How should certificates and notarization be configured for a desktop application developed with Electron so that it can be used properly? The software is distributed via website download.

Hello, I sent this in as a feedback several weeks ago about watchOS 26.2 beta 2 but since the issue is still active now that watchOS 26.2 is in production I'm reposting here for the community. I would also like to submit a DTS about this issue but honestly don't know the best way to go about it and would appreciate advice about that. There seems to be an issue with VPP distribution for our app on watchOS 26.2. When our watchOS companion app is launched after being installed through VPP to a supervised iPhone, it encounters a dyld error before main() or any application code is even called. The same app launches correctly in every other circumstance we could imagine and test: – Installed through VPP on supervised devices running watchOS 26.1. – Installed from the app store (using an apple id) on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through Testflight on a supervised iPhone and paired watch running iOS 26.2 / watchOS 26.2. – Installed through the app store on unsupervised devices running watchOS 26.1 and 26.2. This strongly appears to be a VPP signing issue because we even did the following experiment: Install iPhone and Watch apps through the App Store on a supervised device pair running public iOS 26.2 beta 2 / watchOS 26.2 beta 2. Verify that both apps launch successfully. Use an MDM command to install from VPP over the existing installations Verify that the watch app fails to launch (the iOS app is unaffected) My feedback included some crash logs which I won't be reposting publicly here. Any feedback or ideas appreciated.

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'm starting a new project in Xcode, but the Team ID in the "Signing and Capabilities" section for iOS is different from the one on the website. Is this a problem? Why does Xcode automatically send a different ID when signing?

Hello, I'm currently developing an iOS app that uses SensorKit. Everything works fine in development and testing — the app correctly requests and receives SensorKit permissions on test devices. In my App ID configuration, the SensorKit Reader Access entitlement (com.apple.developer.sensorkit.reader.allow) is included and visible in Xcode under the project’s entitlements list. However, when I try to archive and distribute the app, I get the following errors in Xcode: Provisioning profile failed qualification Profile doesn't support SensorKit Reader Access. Provisioning profile failed qualification Profile doesn't include the com.apple.developer.sensorkit.reader.allow entitlement. Even though my provisioning profile includes this entitlement, Xcode still refuses to distribute the app. Here’s what I’ve confirmed so far: The provisioning profile lists com.apple.developer.sensorkit.reader.allow in its entitlements. SensorKit works perfectly in debug and development builds. The issue only occurs when attempting to distribute (Archive → Distribute App). Could this be because my account has only development entitlement for SensorKit and not the distribution entitlement? If so, how can I verify or request the proper distribution entitlement for SensorKit Reader Access? Thank you for any guidance or confirmation from Apple regarding this entitlement behavior.

When submitting my new build to app store connect directly from dreamflow, I get this error: Failed Step: Flutter build ipa and automatic versioning Building com.pinpictu for device (ios-release)... ════════════════════════════════════════════════════════════════════════════════ No valid code signing certificates were found You can connect to your Apple Developer account by signing in with your Apple ID in Xcode and create an iOS Development Certificate as well as a Provisioning Profile for your project by: 1- Open the Flutter project's Xcode target with open ios/Runner.xcworkspace 2- Select the 'Runner' project in the navigator then the 'Runner' target in the project settings 3- Make sure a 'Development Team' is selected under Signing & Capabilities > Team. You may need to: - Log in with your Apple ID in Xcode first - Ensure you have a valid unique Bundle ID - Register your device with your Apple Developer Account - Let Xcode automatically provision a profile for your app 4- Build or run your project again 5- Trust your newly created Development Certificate on your iOS device via Settings > General > Device Management > [your new certificate] > Trust For more information, please visit: https://developer.apple.com/library/content/documentation/IDEs/Conceptual/ AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html Or run on an iOS simulator without code signing ════════════════════════════════════════════════════════════════════════════════ No development certificates available to code sign app for device deployment Build failed :| Step 10 script Flutter build ipa and automatic versioning exited with status code 1 Please not I am on a windows pc, not a mac. I'm not sure how to clear this error and I am not an experinced coder, so any advice would be greatly appreciated, especially if it is simple and easy to follow.

I'm currently observing a problem similar to this thread https://developer.apple.com/forums/thread/737334 The difference is that this is happening after updating a system extension. Basically same error, sysextd complains it can not check that the system extension is notarized: macOS Error 3 + Error code=-67050. I think macOS (Sequoia 15.3.2 or 15.7.2 if it matters) is wrong in this case for the following reasons: when using spctl assess -t install, the system extension is reported to be correctly notarized. when restarting the Mac, the updated system extension is correctly checked and staged. if I run spctl assess before sysextd tries to check the system extension, it works. I'm currently thinking of 2 reasons why the check does not work: sysextd is somehow trying to work with a cached assessment that has become invalid after the system extension was updated. macOS needs way more time between the update of the files and the request to update the staged extension. I tried adding a 5-second delay. This does not seem to work or at least reliably. I tried just touching the system extension, no positive result. Unfortunately, in macOS Sequoia, it is not possible anymore to reset-default using spctl and see if it solves the issue, at least the next time the update is performed. [Q] Is there some magic operation that would help macOS correctly check the notarization of an updated system extension?

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.