For a React Native iOS release, what do the distribution certificate and the App Store provisioning profile each do when you archive and upload?

## Two artefacts, two questions Apple code signing answers two separate questions, and each has its own artefact: | | Distribution certificate | App Store provisioning profile | |---|---|---| | Answers | *Who* signed this build? | *What* may this signed build be? | | Contains | Your team's public key, issued by Apple | App ID, allowed certificates, entitlements | | Secret part | The private key in the keychain | None; it is a signed file | | Scope | The team, reused across apps | One bundle identifier | | Created in | Apple Developer account, or by Xcode | Apple Developer account, or by Xcode | A React Native app is signed exactly like any native iOS app; the React Native docs say the publishing process is the same, with extra considerations for the JavaScript bundle. ## The distribution certificate - You create a **key pair** on a Mac and Apple issues a **certificate** for its public key. - The certificate plus the **private key** form the signing identity. The private key never leaves the keychain unless exported. - A new Mac or CI machine cannot sign with a certificate unless the private key is also installed there; seeing the certificate listed is not enough. - Certificates have an **expiry date**; after it, new builds cannot be signed with them. ## The App Store provisioning profile - It names one **App ID**, which must match the target's bundle identifier exactly. The React Native docs call this out: check that the Bundle Identifier is the same as the one registered under Identifiers in the developer account. - It lists the **certificates** allowed to sign the app. - It carries the **entitlements** the app may use: push notifications, associated domains, sign in with Apple and so on. The app's entitlements file must not ask for anything the profile does not grant. - It also has an **expiry date**. ## Archiving and uploading a React Native app 1. Open `ios/YourApp.xcworkspace` (the workspace, because CocoaPods adds the React Native pods). 2. Select **Any iOS Device (arm64)** as the destination. 3. Run **Product > Archive**. Archiving builds the **Release** configuration, so the JS is bundled into `main.jsbundle`. 4. In the Organizer, choose **Distribute App**, then **App Store Connect**, then **Upload**. 5. Choose **Automatically manage signing** or **Manually manage signing**. Automatic lets Xcode pick or create the certificate and profile; manual means you select a profile you created. 6. The build then appears in App Store Connect, ready for testing and submission. ## When signing fails | Symptom | Usual cause | |---|---| | No profile matches the bundle identifier | Bundle ID differs from the App ID, often after renaming the app | | Certificate shown but "missing private key" | The key pair was created on another Mac | | Profile does not include an entitlement | A capability, such as push, was added after the profile was generated | | Profile or certificate expired | The dates passed; a new one is needed | ## The scenario: a parking app adds push reminders A parking app adds push notifications to remind drivers before a session ends. The Debug build on a phone works, because development signing uses a separate development profile. The Release archive fails: the App Store profile was generated before the push capability was enabled, so it lacks the entitlement. Regenerating the App Store profile after enabling the capability, or letting automatic signing refresh it, fixes the archive. ## What ends up in the signed archive It helps to know what an `.xcarchive` for a React Native app carries, because each item has its own failure mode: - The **signed app**, with the distribution certificate's signature. - The **embedded provisioning profile** that authorised the signing, which is how the entitlements travel with the app. - **`main.jsbundle`** and the JS images, produced by the Release bundling phase. - **dSYMs**, the debug symbols for the native code, which stay with the archive rather than the app. ## Automatic or manual? - **Automatic** suits small teams and one release machine; Xcode keeps profiles current. - **Manual** gives predictable, reviewable signing and suits shared release machines, at the cost of regenerating profiles yourself. - Either way, the private key for the distribution certificate must be backed up; sharing it across a team is a separate topic.