Membership, Signing, Capabilities and Info.plist

A code signature seals an app’s executable, resources and entitlements with a private key, so the system can check that nothing changed since signing and who signed it. Signing needs a code-signing identity: a certificate that Apple issued to your team, plus the private key that matches the public key in it. A certificate on its own is public data and cannot sign anything.

The signature says who signed the code. Apple platforms other than macOS also need to know that Apple authorized this code to run, and that is what a provisioning profile does. Apple’s technote TN3125 describes a profile as the answer to five questions:

Apple signs the profile, Xcode embeds it in the bundle, and the device checks both the profile and the app’s signature before it launches the app. When a build goes through the App Store, Apple checks it and then re-signs it with its own credentials, so the installed copy carries no profile and never expires. Your certificate and profile only need to be valid when you upload.

You can build and run on your own devices with a free Apple Account, as Getting Started with Apple Platforms explains with a side-by-side table. To distribute an app (TestFlight, the App Store, ad hoc builds, or notarized Mac apps), and for most capabilities FieldNotes uses, a team needs a paid membership. There are three kinds:

See Apple Developer Documentation — Enrollment and Apple Developer — Apple Developer Enterprise Program.

The fees come from the Apple Developer Program page as it read on 2026-09-24; they vary by country and change over time, so check the page before enrolling. The Enterprise Program is not an alternative App Store account. Apple only accepts it for proprietary apps that the App Store, custom apps, ad hoc distribution or TestFlight can’t serve, and an in-house certificate that is revoked stops every installed copy from launching. FieldNotes is an organization membership, because a company publishes it and several developers work on it.

Inside a team, roles decide who can do what. The Account Holder accepts agreements and is the only one who can do certain legal tasks. Admins can create distribution certificates and manage members; App Managers manage apps in App Store Connect; Developers can build and run but, by default, cannot create distribution certificates. An Account Holder, Admin or App Manager can also turn on Automatic Signing Controls, which stop the Developer role from registering new App IDs or devices through Xcode’s automatic signing, which is useful when the device slots are a shared resource.

Every signing asset is tied to the team’s ten-character Team ID. Apple puts it in the Organizational Unit field of each code-signing certificate, so the quickest way to find it on a Mac is to list your identities:

See Apple Developer Documentation — TN3161: Inside Code Signing: Certificates and Apple Developer Documentation — Apple Developer Program Roles.

The value in parentheses after Apple Development is the developer’s personal identifier, not the team; the one after Apple Distribution is the Team ID. security find-identity only searches keychain files, so an identity that lives in cloud-managed signing doesn’t appear there.

A certificate type states what the identity may sign. The ones an app team meets are:

See Apple Developer Documentation — Certificates overview.

Older names (iOS Development, iOS Distribution, Mac Development, Mac App Distribution) are the pre-Xcode 11 types; new projects never need them. The APNs keys and certificates in the same list are server credentials, covered on Notifications, APNs and Live Activities.

Apple issues certificates in three ways, and the difference is where the private key lives:

Development and distribution certificates are typically valid for a year. When one expires, apps already on the App Store are unaffected (they were re-signed by Apple), but you can’t upload new builds with it; a revoked distribution certificate can also invalidate builds that were uploaded but not yet submitted. Before debugging a signing error, check which identity actually signed the build and the chain of trust behind it:

See Apple Developer Documentation — TN3161: Inside Code Signing: Certificates and Apple Developer Documentation — Cloud-managed certificates.

To share a team’s distribution identity with another developer’s Mac without cloud signing, Xcode can export and import signing assets; Apple describes it in Synchronizing code signing identities with your developer account. Treat the exported .p12 like a password: never commit it, and in CI store it as an encrypted secret (see CI/CD with Xcode Cloud and the Command Line).

The bundle ID is the reverse-DNS string in CFBundleIdentifier that identifies the app on the device and in App Store Connect. The App ID is the record in the developer account that registers it: the team prefix, a dot and the bundle ID, ABCDE12345.com.example.fieldnotes. An explicit App ID matches exactly one bundle ID; a wildcard App ID (ABCDE12345.com.example.*) matches many, which is fine for quick experiments but can’t carry most capabilities (iCloud, push, App Groups, Sign in with Apple), so FieldNotes uses explicit IDs throughout.

Every target is its own bundle and needs its own App ID. An embedded bundle’s ID must start with the bundle ID of the bundle it is embedded in, followed by a dot: the watch app and the iPhone-side extensions start with com.example.fieldnotes., and the watch widget extension, which is embedded in the watch app, starts with com.example.fieldnotes.watchkitapp.:

See Apple Developer Documentation — Register an App ID.

The watch widget row is the one that follows the rule one level down: its bundle ID extends the watch app’s, not the iPhone app’s. For the same reason, a watch-side extension of any other kind would need an ID under com.example.fieldnotes.watchkitapp., never directly under com.example.fieldnotes..

With automatic signing, Xcode registers each App ID the first time you build the target. The IDs come from the PRODUCT_BUNDLE_IDENTIFIER build setting, which FieldNotes derives from one base value so a fork only has to change it once:

See Apple Developer Documentation — CFBundleIdentifier.

A target-level file only overrides what differs: the project-level Base.xcconfig already defines FIELDNOTES_BUNDLE_ID_BASE, and target settings sit above project settings in Xcode’s precedence order.

The bundle ID is permanent once an app is on the App Store: App Store Connect ties the app record, its reviews and its purchases to it. The App ID prefix is the Team ID for every app created today; some very old apps have a different, legacy prefix that must be kept.

At runtime the app can read its own identity, which FieldNotes shows in the About section of Settings and attaches to support emails:

See Apple Developer Documentation — bundleIdentifier and Apple Developer Documentation — CFBundleVersion.

BuildIdentity complements the Bundle.main.appVersion shortcut used by SettingsView on Controls, Forms, Text, Images and SF Symbols; it adds the bundle ID and build number, which matter when the same version exists as several TestFlight builds.

A development or ad hoc build only installs on devices whose identifiers are listed in its profile. A team can register up to 100 devices per product family (iPhone, iPad, Apple Watch, Apple Vision Pro, Mac, Apple TV) per membership year. Disabling a device doesn’t free its slot; at the start of each membership year, the Account Holder, an Admin or an App Manager can remove devices and get the full count back. With automatic signing, Xcode registers a device when you first run on it. For testers' devices you don’t have at hand, collect the identifiers and upload them in bulk as a tab-separated file, whose first row is ignored:

See Apple Developer Documentation — Devices overview and Apple Developer Documentation — Register multiple devices.

Registered devices matter only for development and ad hoc distribution. TestFlight and the App Store install on any device, so beta testers never need a slot, which is one more reason to prefer TestFlight over ad hoc builds.

Developer Mode is the device-side half of the same protection. An iPhone, iPad, Apple Watch or Apple Vision Pro refuses to launch development-signed apps (from Xcode, or an .ipa installed with Apple Configurator) until someone turns on Settings > Privacy & Security > Developer Mode, restarts, and confirms with the passcode. The switch appears only after the device has been paired with a Mac. It doesn’t affect App Store or TestFlight installs, the Mac has no equivalent, and on Apple TV pairing alone is enough. The steps and the new Xcode 27 network pairing are in Getting Started with Apple Platforms; from the command line, a device without Developer Mode fails at the install or launch step:

See Apple Developer Documentation — Enabling Developer Mode on a device.

Needs a physical device paired with the Mac, and a development profile that lists its identifier.

A provisioning profile is a property list wrapped in a signature from Apple. Each distribution method has its own profile type:

See Apple Developer Documentation — TN3125: Inside Code Signing: Provisioning Profiles.

Xcode embeds the profile at FieldNotes.app/embedded.mobileprovision (on the Mac, FieldNotes.app/Contents/embedded.provisionprofile). Profiles expire, usually within a year (Developer ID profiles last much longer), and any change to the inputs, such as a new device, a new capability or a renewed certificate, makes Apple issue a new one. The Mac is the exception to "no profile, no launch": a Mac app that claims only unrestricted entitlements (App Sandbox, hardened runtime, App Groups) needs no profile, even on the Mac App Store. A restricted entitlement such as iCloud, push or Sign in with Apple needs one, and TestFlight always does.

When a build won’t install, compare what the profile allows with what the signature claims. The profile is a CMS envelope; the security tool unwraps it:

See Apple Developer Documentation — TN3125: Inside Code Signing: Provisioning Profiles.

Apple notes that the property list view is for understanding and debugging only. Modern systems read the DER-Encoded-Profile property inside it, and the format may change, so never build tooling that parses profiles.

With automatic signing (Automatically manage signing in the Signing & Capabilities tab, CODE_SIGN_STYLE = Automatic), Xcode creates your development certificate, registers the App IDs, capabilities and devices, and generates Xcode Managed profiles as needed. When you distribute from the Organizer it picks the distribution identity, using a cloud-managed certificate if none is in the keychain. FieldNotes uses automatic signing for Debug on every developer’s Mac, with the team in the untracked Signing.xcconfig shown on Getting Started with Apple Platforms.

With manual signing (CODE_SIGN_STYLE = Manual), you create the profiles in the developer account and name, per target and configuration, which identity and which profile to use. Choose it when a build machine must not talk to the developer account, when a security team controls distribution identities, or when you need a specific profile, such as an ad hoc one. It is also more work: every new device or capability means regenerating and re-installing profiles.

A common split is automatic for Debug and manual for Release. The project-level Release.xcconfig applies to every target, so the signing choice goes into a file mapped only to the app target’s Release configuration:

See Apple Developer Documentation — Build settings reference.

Each extension target sets its own PROVISIONING_PROFILE_SPECIFIER in its own .xcconfig, because a profile covers exactly one App ID, and the Mac build needs a Mac profile of its own, hence the [sdk=macosx*] line. Build configuration files, their precedence and SDK-conditional settings are explained on Xcode Projects, Targets, Schemes and Previews and One Codebase for iOS, iPadOS, macOS, watchOS and visionOS.

Automatic signing also works headless. xcodebuild can create or update profiles during the build when you pass -allowProvisioningUpdates and authenticate with an App Store Connect API key instead of an Apple Account. The key file is a secret stored outside the repository; the placeholders below stand for your own values:

See Apple Developer Documentation — Distributing your app for beta testing and releases and Apple Developer Documentation — Creating API Keys for App Store Connect API.

Needs a paid membership and an App Store Connect API key with a role that may manage signing. Exporting and uploading that archive is covered on App Store Connect, TestFlight and App Review, and the full CI setup on CI/CD with Xcode Cloud and the Command Line.

A capability is a feature that needs Apple’s permission, switched on in the Signing & Capabilities tab with + Capability. Adding one does three things: it writes entitlements into the target’s .entitlements file, enables the capability on the App ID so new profiles allow it, and sometimes adds Info.plist keys or frameworks. The entitlements file is only a request; the profile is the allowlist; a key in the file that the profile doesn’t allow makes the build fail to sign or install.

These are the five canonical capabilities of the FieldNotes app target, all in one file:

See Apple Developer Documentation — Adding capabilities to your app and Apple Developer Documentation — Entitlements.

Needs a paid Apple Developer Program membership: iCloud containers, App Groups, push and Sign in with Apple are registered to a team, and a Personal Team can’t use them.

Other pages add their own keys to the same file: HealthKit and NFC on Health, Motion and Accessories, App Attest on Security and Privacy, and the Private Cloud Compute entitlement on Apple Intelligence and Machine Learning. What each key does is explained on those pages and on Core Data, CloudKit and iCloud; this section is about how they get into a signed build. A few rules differ by platform and target:

See Apple Developer Documentation — Provisioning with managed capabilities and Apple Developer Documentation — Enabling enhanced security for your app.

A missing entitlement often fails silently at runtime rather than at build time: an App Group container URL comes back nil, and CloudKit reports a missing container. FieldNotes catches that in Debug builds at launch:

See Apple Developer Documentation -- containerURL(forSecurityApplicationGroupIdentifier:) and Apple Developer Documentation — Configuring app groups.

The app and each extension call EntitlementCheck.verifyAppGroup() once at startup in Debug builds, before SharedNoteAccess opens the store (see Widgets, Complications and Controls (WidgetKit)). On macOS a group identifier with the group. prefix must also be registered for the team, as the App Groups section of App Intents, Siri, Shortcuts, Spotlight, Deep Links and Extensions explains.

The information property list is what the system and the App Store read about the bundle. Xcode Projects, Targets, Schemes and Previews shows how generated keys (INFOPLIST_KEY_...) and a hand-written plist combine; this section lists the keys that matter for signing and review.

Since the 26 releases, the app icon is one layered Icon Composer file instead of an AppIcon set of flat images. The same file serves iOS, iPadOS, macOS, watchOS and the App Store, and the system renders its default, dark, clear and tinted appearances with Liquid Glass. Icon Composer 2.0 in Xcode 27 adds refraction and outside specular highlights for the 27 releases while keeping the 26 rendering. How to design and layer the artwork is on Liquid Glass, Materials and Icons; for the build, three settings matter:

See Apple Developer Documentation — Creating your app icon using Icon Composer and WWDC25 — Create icons with Icon Composer.

The App Icon field in the target’s General tab is that build setting, and it must equal the Icon Composer file’s name without the extension; you can keep several icon files in a project, but only the matching one ships. Because FieldNotes supports the 26 releases, Xcode also renders flat icon images from the same file at build time for older design generations, so there is no second icon to maintain. App Store Connect takes the store icon from the uploaded build.

Most signing failures are one of a handful of mismatches. Checking them in this order usually finds the cause:

The commands above (security find-identity, codesign --display, security cms -D) answer each question from the build itself rather than from Xcode’s summary, which is what TN3125 and TN3161 recommend when Xcode’s messages are not enough.