# AppInChina iOS Distribution Documentation > This file contains the AppInChina iOS Distribution documentation concatenated into > a single document. You can paste it into an AI assistant (ChatGPT, Gemini, > Claude, etc.) to ask questions about your iOS Distribution integration. > > Generated automatically at build time. --- Apple may reject your app under **App Store Review Guideline 4.3(a)** if it believes your app duplicates the content or functionality of another app on the App Store — even if both apps belong to the same company or are authorized copies. This rejection is commonly referred to as a **“spam rejection.”** ## What triggers this? - Reusing the same codebase, design, or app template across different App Store accounts - Submitting multiple similar apps from different developer accounts - Submitting localized versions of an app without clear differentiation - Apps submitted by a distributor or agent without proper authorization ## Why this affects you When we submit your app to the China App Store through our **Apple Developer China account**, Apple may detect that the same app is already available globally under your company’s own developer account. Even though this distribution is fully authorized, Apple’s automated or manual review process may mistakenly flag it as a duplicate submission—especially if the app design, features, and content are nearly identical. ## How we resolve it We’ve found two effective solutions: 1. **Exclude Mainland China** from your global App Store Connect listing. This avoids duplication by ensuring only our version appears in the China App Store. 2. **Submit an authorization letter.** If you prefer to keep Mainland China enabled in your global listing, we can submit a formal authorization letter to Apple confirming that AppInChina is permitted to publish the app in China on your behalf. :::warning Tell us early Please let us know upfront if your app is already listed globally so we can apply the correct approach and avoid rejections. ::: --- This guide explains how to configure your CI/CD pipeline or signing tools to work with AppInChina's managed iOS distribution system. ## The core constraint :::warning No Apple Developer account access Your CI/CD pipeline or signing tools must **not** rely on direct access to the Apple Developer account. ::: Since certificates, provisioning profiles, identifiers, and APNs credentials are centrally managed by AppInChina, your build/signing process must use the files we provide—**without requiring Apple Developer account credentials or API access**. This means you cannot use tools or workflows that dynamically fetch, create, or modify signing resources from Apple's systems. ## What won't work The following tools and approaches will **not** work in this setup: ### Fastlane automatic provisioning tools (not supported) - `fastlane match` - requires read/write access to the Apple Developer Portal - `fastlane sigh` - attempts to download or create provisioning profiles from Apple - `fastlane cert` - tries to create or download certificates from Apple - `fastlane pem` - generates APNs certificates (we provide these) ### Xcode automatic signing (not supported) - **"Automatically manage signing"** in Xcode - requires Apple Developer account access - Xcode cloud builds with automatic signing ### Scripts or tools that modify Apple resources (not supported) - Scripts that register devices via Apple's APIs - Tools that create App IDs, capabilities, or App Groups programmatically - Automated APNs certificate generation - Any tool that requires App Store Connect API keys for signing/provisioning operations ### Third-party services with Apple portal integration (not supported) - CI/CD services configured to auto-fetch provisioning profiles from Apple - Build services that require Apple Developer Portal credentials ## What will work: manual signing with provided assets Your build process should use **manual signing** with the certificates and provisioning profiles we provide. ### Supported approaches - **Manual signing in Xcode** with our provisioning profiles - **xcodebuild** with signing options pointing to our files - **fastlane gym** (build only, not provisioning management) - **CI/CD pipelines** that reference stored signing assets - **Local builds** with manually configured signing ## Recommended approach Your build and signing process should use **manual signing** with the certificates and provisioning profiles we provide via 1Password. **General principles:** 1. **Receive signing assets** - We'll deliver certificates (`.p12`, `.cer`) and provisioning profiles (`.mobileprovision`) via 1Password 2. **Install locally** - Import certificates into your keychain and install provisioning profiles for local development 3. **Configure manual signing** - In Xcode, disable "Automatically manage signing" and select our provisioning profiles 4. **Store securely in CI/CD** - Add signing assets as encrypted secrets in your CI/CD platform (often base64-encoded) 5. **Reference in builds** - Configure your build commands to use the provided signing assets ## Best practices 1. **Store signing assets securely**: - Use your CI/CD platform's encrypted secrets - Never commit `.p12` or `.mobileprovision` files to version control - Use base64 encoding for storing binary files as secrets 2. **Keep ExportOptions.plist in version control**: - This file contains export configuration - Safe to commit (no secrets) - Update when provisioning profiles change 3. **Document your signing configuration**: - Team ID - Bundle IDs - Provisioning profile names - Certificate common name ## Troubleshooting ### "No valid code signing certificates found" - Certificate not installed in keychain - Certificate password incorrect - Keychain locked or not accessible **Solution**: Verify certificate import and keychain unlock steps. ### "No provisioning profile matches" - Bundle ID mismatch - Provisioning profile not installed - Wrong profile selected in Xcode **Solution**: Ensure Bundle ID exactly matches provisioning profile, verify profile is installed. ### Build succeeds but IPA export fails - ExportOptions.plist misconfigured - Wrong export method - Provisioning profile doesn't support export method **Solution**: Verify ExportOptions.plist matches your provisioning profile type. ## When assets are renewed Certificates and provisioning profiles have expiration dates. When we renew them: 1. You'll receive new files via 1Password 2. Update the files in your CI/CD secrets (re-encode to base64) 3. Update local installations 4. No code changes needed—just replace the files We'll notify you before expiration and provide updated assets with sufficient lead time. ## Summary **Do**: - Use manual signing with provided certificates and provisioning profiles - Store signing assets securely in CI/CD secrets - Reference local signing files in your build process - Use fastlane for building (not provisioning management) **Don't**: - Use automatic signing in Xcode or CI/CD - Use tools that fetch/create provisioning profiles from Apple - Require Apple Developer account credentials in your pipeline - Attempt to modify Apple resources programmatically --- ## Understanding the system ### What is a distribution certificate, and why is it shared? A distribution certificate is required to sign and submit apps to the App Store. Our shared certificate approach streamlines management, avoids certificate limits, and simplifies renewals. ### What’s the difference between development and distribution provisioning profiles? - **Development profiles** allow you to test your app on registered devices. - **Distribution profiles** are required to release your app on the App Store. ## Setup and access ### Do I need to register test devices? Yes, for development profiles. Please provide each device’s UDID and name. ### Can I manage my app directly in App Store Connect? Yes. We’ll assign roles to your team so you can manage your app. Certificates, provisioning profiles, identifiers, and APNs credentials remain managed by AppInChina. ### How do I update my app’s capabilities later? Inform us of any changes. We’ll update the App Identifier and regenerate the necessary provisioning profiles and APNs certificates if required. ### Can you manage App Groups or Merchant IDs for my app? Yes. We support App Groups, Merchant IDs, and other Apple service identifiers. ### Can my CI/CD pipeline fetch profiles or certificates automatically from the Apple Developer portal? No. Configure your pipeline to use the files we provide directly. ### Why can’t I upload my app directly from Xcode? Uploading a build directly from Xcode requires access to the **Apple Developer Program** account that owns the app’s certificates and provisioning profiles. In our shared distribution certificate setup, AppInChina centrally manages all Apple Developer account resources to ensure security, consistency, and compliance. Client teams are therefore **not granted Developer Program access**, even if they have App Store Connect roles. To submit builds without Developer Program access, please **export an IPA from Xcode and upload it using Apple Transporter**. ## Support and communication ### Who do I contact for support with certificates, provisioning profiles, or APNs? Please reach out to our support team or your account manager. ### What should I include in my support request? Include a description of the issue, relevant error messages, and affected Bundle IDs. ## Security & data handling ### Is sharing certificates and provisioning profiles via 1Password secure? Yes. 1Password uses end-to-end encryption. Restrict access to authorized personnel only. ### How can we verify that the certificates and provisioning profiles belong to our app? You can inspect the `.mobileprovision` file on macOS to confirm the App ID, Team ID, entitlements, and validity period. ## Project lifecycle and admin ### What happens if we stop working with AppInChina? We’ll revoke App Store Connect access and stop maintaining Apple Developer resources for your app (certificates, profiles, identifiers, APNs). Note: Apple test device registrations cannot always be removed immediately (Apple restrictions apply, and devices may remain registered until the membership year resets). We will not register new devices for your app after offboarding. ### How long does the setup take? After receiving all required information, setup typically takes 1–3 business days. ### How often are certificates and provisioning profiles renewed? Certificates generally have a one-year validity. Shared certificates may have an initial shorter validity (but never less than six months). We handle renewals and distribute updated files proactively. --- To get started, please provide the following information as completely and accurately as possible. Missing or incomplete information may result in delays during setup, testing, or app submission. :::tip Verify your information After gathering your details, use the **[Preparation Checklist](./preparation-checklist.md)** to ensure you have everything ready before submitting. ::: ## 1) App identifiers (Bundle IDs) For each iOS app you plan to distribute, please provide: - **Desired Bundle ID** (example: `com.yourcompany.yourapp`) - **App name**, as it should appear in App Store Connect - **List of required app capabilities**, such as (but not limited to): - Push Notifications - In-App Purchases - Sign in with Apple - Associated Domains - App Groups > **Note:** Capabilities must be listed upfront. Adding or changing capabilities after setup may require updating the App Identifier and regenerating provisioning profiles. :::caution Ensure Bundle ID is globally available **Bundle IDs must be globally unique across ALL Apple Developer accounts.** Each Bundle ID can only be registered once worldwide. If you're already distributing your app globally with your own Apple Developer account, you **cannot reuse the same Bundle ID**. You must provide a different Bundle ID for the China-specific version (e.g., `com.company.appname.china`). ::: :::warning Submit this early We cannot proceed with creating App Identifiers, provisioning profiles, or initiating required filings until your Bundle ID and capabilities are confirmed. If the chosen Bundle ID is unavailable and we are forced to change it after filings have started, we may need to redo registrations such as: - Mobile App Filing (备案) - Software Copyright Certificate - ICP registration - User-facing documents (privacy policies, terms of service, etc.) We strongly recommend confirming your desired Bundle ID with us **before** we begin any filing procedures. We can check and reserve your proposed Bundle ID in our Apple Developer account before proceeding. ::: :::info Global availability (App Store Connect) Please confirm whether this app is **already listed globally** on the App Store under your own Apple Developer account. If the same app is already available internationally, Apple may flag the China-specific version as a duplicate submission (Guideline 4.3(a)). We have two standard solutions: - Exclude Mainland China from your global App Store listing, or - Provide an authorization letter stating AppInChina is permitted to submit the app in China on your behalf See also: **[App Review Guideline 4.3(a): Duplicate App Rejection](./app-review-duplicate-4-3a.md)**. ::: ## 2) Provisioning profiles For each provisioning profile you require, specify: - **Associated Bundle ID** (must exactly match the App Identifier) - **Profile type**: - **Development**: internal testing and debugging on registered devices - **Distribution**: App Store release or other distribution methods - **Target usage** (local development, CI/CD builds, TestFlight, etc.) - **Device UDIDs** (required only for development profiles) Provisioning profiles are generated and managed by AppInChina. Any change to certificates, devices, or app capabilities may require profiles to be regenerated. ## 3) Test devices (development profiles only) Test devices are required only for **development provisioning profiles**. Due to Apple’s annual device registration limits, test devices are capped per device type and cannot be removed once registered for the current membership year. Per app, the default limits are: - iPhone: up to 3 devices - iPad: up to 3 devices Additional devices may be approved subject to availability and with appropriate technical or business justification. Approval is not guaranteed. For each test device, please provide: - **Device name** (example: “John’s iPhone 14”) - **UDID** (Unique Device Identifier) ## 4) App Store Connect access At least one member of your team must have access to **App Store Connect** to manage app metadata, monitor review status, respond to Apple inquiries, and handle compliance-related requests. :::tip Access prerequisites (avoid onboarding delays) Before you request access, confirm each team member: - Has an active Apple ID they can sign into - Has **two-factor authentication (2FA)** enabled and access to the trusted device/phone number - Can receive and accept Apple email invitations promptly ::: For each user who requires access, please provide: - **Full name** - **Email address** (must match the email associated with the user’s Apple ID) - **Requested role** (example: App Manager, Developer, Marketing) - **Brief description of responsibilities** Important notes: - The highest level of access we can grant is **App Manager**. - If you are responsible for uploading builds with **Apple Transporter**, request **App Manager** access. - Please follow the principle of least privilege and request only the permissions strictly necessary. - Each user must accept the invitation sent by Apple to activate their access. ## 5) App Groups and additional identifiers (if applicable) If your app requires additional Apple identifiers, please provide details: - **For App Groups**: - Desired App Group name (example: `group.com.yourcompany.yourapp`) - Apps and provisioning profiles that should be associated with the App Group - Purpose (example: shared storage, app extension communication) - **For embedded extensions or widgets**: - Bundle ID for each embedded target (example: `com.yourcompany.yourapp.todayextension`) - Component name (example: “Today Widget”, “Watch Extension”) - Whether it is intended to be a standalone app in App Store Connect (Yes/No) :::tip Placeholder app records to reduce cross-client visibility In our shared Apple Developer / App Store Connect organization, identifiers like Bundle IDs (including internal-only targets such as widgets or extensions) can appear in dropdowns and selectors. To reduce accidental exposure, we can create **placeholder app records** for internal-only Bundle IDs so that: - The identifier is removed from “available identifiers” dropdowns shown to other clients - We reduce the chance of accidental discovery during setup workflows - We prevent accidental reuse of identifiers These placeholder apps are not published and contain no metadata or assets. ::: Important: please review the disclosure in **[Introduction & Architecture](./introduction.md)** about cross-client visibility in shared App Store Connect organizations. For other identifiers (such as Merchant IDs), include: - Identifier type - Desired name/format (if applicable) - Purpose and integration details ## 6) Push notifications (APNs) If your app uses **Apple Push Notification service (APNs)**: - Clients always send push notifications from their **own backend systems** - AppInChina manages all APNs configuration within the Apple Developer Account - We use **certificate-based APNs authentication** in our shared account environment For each app with push notifications enabled, AppInChina will securely provide: - **APNs SSL certificate (`.cer`)** - **APNs private key bundle (`.p12`)** APNs Auth Keys (`.p8`) are not used or shared in our shared Apple Developer account setup. If your app requires special push notification types (background notifications, VoIP pushes, Live Activities), inform us upfront so we can configure the App Identifier and provisioning profiles accordingly. --- This page explains the architecture of our shared distribution model, the responsibility split between AppInChina and your team, and how we manage signing assets securely. :::warning Shared App Store Connect model: cross-client visibility is possible Our iOS distribution model uses a **shared App Store Connect organization** (multiple clients access the same organization, with role-based permissions). Because App Store Connect was **not designed for multi-tenant sharing**, there are workflows where **Client A may be able to see limited information related to Client B’s apps**. This can happen due to how Apple surfaces data across certain screens and request flows. Examples include: - App creation flows where app identifiers or related targets appear in selection lists - Certain App Store Connect request flows (for example, expedited review requests) where app lists or identifiers may be visible We take practical measures to reduce this (least-privilege roles, internal process controls, and placeholder records where applicable), but **we cannot guarantee zero cross-client visibility in all App Store Connect workflows**. By proceeding, you confirm you understand and accept that **some cross-client visibility is possible** under this shared-account model. ::: :::info No direct Apple Developer account access **Your team will not have direct access to the Apple Developer account.** This means: - All certificates, provisioning profiles, App IDs, and related resources are created and managed by AppInChina - You receive signing assets securely via 1Password - **Your build tools, CI/CD pipelines, and signing scripts must NOT depend on direct access to the Apple Developer Portal or App Store Connect APIs** - Tools like `fastlane match`, `fastlane sigh`, or scripts that auto-generate/fetch provisioning profiles from Apple will not work - You must use the certificates and provisioning profiles we provide If your current build process requires Apple Developer account access, you'll need to adapt it to work with manually provided signing assets. See **[CI/CD Pipelines and Signing Tools](./cicd-signing.md)** for details. ::: ## Responsibility split (who does what) To avoid delays and confusion, here’s the typical responsibility split: - **AppInChina manages (inside Apple Developer / App Store Connect)**: - Certificates, provisioning profiles, App IDs, capabilities, APNs certificates - App Store Connect role assignment (up to App Manager) - Renewals and re-issuing updated signing assets when needed - **Your team manages (outside of Apple Developer access)**: - App code, builds, and CI/CD configuration - App metadata/content in App Store Connect (screenshots, descriptions, privacy, compliance responses) - Exporting the IPA and uploading builds using **Apple Transporter** ## Our management system (high level) We use a **Shared Distribution Certificate** system to efficiently manage multiple client apps within our Apple Developer China account. AppInChina takes care of: - **Distribution certificates**: issue and renew shared certificates for app signing - **App identifiers (Bundle IDs)**: create and manage your unique App ID - **Additional identifiers**: App Groups, Merchant IDs, and other related services (when needed) - **Provisioning profiles**: generate development and distribution profiles - **Test devices**: register testing devices when required (development profiles only) - **App Store Connect access**: manage roles and permissions for your team members - **Push notifications (APNs)**: configure APNs and provide the required credentials Our team keeps these components up to date and securely managed. ## Onboarding & maintenance process When onboarding a new app: 1. **Information collection**: we gather your Bundle ID, required capabilities, and any additional identifiers. 2. **Resource setup**: we create your App Identifier, assign a shared certificate, configure APNs (if needed), and generate provisioning profiles. 3. **Secure delivery**: we share the required signing and APNs files (e.g., `.p12`, `.cer`, `.mobileprovision`) via 1Password. 4. **Ongoing maintenance**: as certificates near expiration, we renew and re-issue updated profiles/certificates and send you the updated files. :::tip 1Password access We deliver signing assets via 1Password. To avoid delays, ensure at least one person on your team can access the 1Password shared vault we provide. ::: You integrate these files into your CI/CD pipeline or local environment to build, sign, and distribute your app as usual—without requiring direct Apple Developer account access. --- This documentation explains how AppInChina manages iOS app distribution through our Apple Developer China accounts and what we need from you to onboard your app smoothly. ## Recommended Reading Path Depending on your role, we recommend starting with different sections of the documentation. ### For Product Managers & Ops If you are managing the app submission, compliance, or Apple Developer account requirements: 1. **Understand the model**: Read [Introduction & Architecture](./introduction.md) to understand how our shared account model works and why you won't have direct access. 2. **Gather requirements**: Review the [Information We Need From You](./information-required.md) guide to understand and gather all the necessary information in the required format. 3. **Verify readiness**: Use the [Preparation Checklist](./preparation-checklist.md) to ensure you have everything ready before submitting your email. ### For Developers If you are building, signing, and uploading the app: 1. **Understand the constraints**: Read [Introduction & Architecture](./introduction.md) (specifically "No direct Apple Developer account access") to understand the manual signing requirement. 2. **Configure your pipeline**: Read [CI/CD Pipelines and Signing Tools](./cicd-signing.md) to learn how to set up manual signing without API access. 3. **Upload builds**: Read [Uploading via Transporter](./transporter-upload.md) to learn the correct workflow for submitting builds to App Store Connect. --- Before submitting your information, use this checklist to ensure you have everything ready. Gathering these details upfront will help us onboard your app quickly and avoid delays during setup or submission. ## Required Information Checklist ### ✅ App Identifiers (Bundle IDs) - [ ] **Desired Bundle ID** (e.g., `com.yourcompany.yourapp`) - [ ] **App name** (as it should appear in App Store Connect) - [ ] **List of required capabilities**, such as: - Push Notifications - In-App Purchases - Sign in with Apple - Associated Domains - App Groups - [ ] **Global App Store status** – Confirm whether this app is already listed globally on the App Store under your own Apple Developer account :::warning Bundle ID is critical The Bundle ID is used across multiple regulatory filings (备案, ICP, Software Copyright). Changing it after we start those processes may require restarting them entirely. We recommend confirming your Bundle ID with us **before** we begin any filings. ::: :::caution Bundle ID must be globally unique **Bundle IDs must be globally unique across ALL Apple Developer accounts worldwide.** Before submitting your desired Bundle ID, verify that: - No one on your team has already registered it in another Apple Developer account - It follows Apple's reverse-DNS naming convention (e.g., `com.company.appname` based on a domain you own) **Common scenario**: If you already distribute your app globally using your own Apple Developer account. You must use a **different Bundle ID** for the China-specific version (e.g., add `.china` suffix like `com.company.appname.china`). ::: ### ✅ Test Devices (only if requesting Development profiles) - [ ] **Device name(s)** (e.g., "John's iPhone 14") - [ ] **Device UDID(s)** for each test device - [ ] Confirm you need **≤3 iPhones and ≤3 iPads per app** (our standard limits) :::info Why device limits? Apple enforces annual device registration limits per Apple Developer account. Once devices are registered, they cannot be removed until the next membership year. We apply per-app limits to ensure fair distribution across all clients. ::: ### ✅ App Groups & Additional Identifiers (if applicable) Only complete this section if your app uses App Groups, extensions, widgets, or other special identifiers. - [ ] **For App Groups**: - [ ] Desired App Group name (e.g., `group.com.yourcompany.yourapp`) - [ ] Apps and provisioning profiles that should be associated - [ ] Purpose (e.g., shared storage between app and extension) - [ ] **For embedded extensions or widgets**: - [ ] Bundle ID for each target (e.g., `com.yourcompany.yourapp.widget`) - [ ] Component name (e.g., "Today Widget", "Watch Extension") - [ ] Whether it should be a standalone app in App Store Connect (Yes/No) - [ ] **For other identifiers** (Merchant IDs, etc.): - [ ] Identifier type - [ ] Desired name/format - [ ] Purpose and integration details ## Next Steps Once you've gathered all the required information: 1. **Double-check against requirements**: Ensure your information matches the format in [Information We Need From You](./information-required.md) 2. **Submit your information** via email to your AppInChina Engineering contact 3. **Wait for setup confirmation** – we'll create all necessary resources and deliver signing assets via 1Password If you have questions about any of these items, refer to: - **[Introduction & Architecture](./introduction.md)** – understand how our distribution system works - **[FAQ](./faq.md)** – common questions and answers - **[Troubleshooting](./troubleshooting-screenshots.md)** – solutions to common issues Or reach out to your AppInChina Engineering contact for clarification. --- In our managed distribution setup, **distribution builds must be uploaded using Apple Transporter**, not directly from Xcode. This approach allows you to submit builds to App Store Connect **without requiring access to the Apple Developer account**. ## Important rules (please read) - Do **not** upload builds using **Xcode → Distribute App → Upload** - Do **not** enable “Automatically manage signing” - Sign your app using the certificate and provisioning profiles provided by AppInChina - Always **export an IPA** and upload it using **Apple Transporter** Uploading via Xcode requires Apple Developer Program access, which is not part of this setup. ## Step 1: Export the IPA from Xcode After building and signing your app with the files we provide: 1. Open your project in **Xcode** 2. Select **Any iOS Device (arm64)** as the run destination 3. From the menu bar, click: ``` Product → Archive ``` 4. When **Organizer** opens, select the latest archive 5. Click **Distribute App** 6. Select **Custom** → **Next** 7. Select **App Store Connect** → **Next** 8. Select **Export** (do **not** select Upload) 9. Keep all signing options unchanged 10. Choose a location and export the `.ipa` You should now have a signed IPA ready for upload. ## Step 2: Upload the IPA using Apple Transporter 1. Install **Apple Transporter** from the macOS App Store 2. Open **Transporter** 3. Sign in using your **App Store Connect Apple ID** (must have **App Manager** access) - Ensure you can complete Apple **2FA** prompts during sign-in 4. Click **Add App or Asset Pack** and select the exported `.ipa` 5. Wait for Transporter to validate the build 6. Click **Deliver** 7. Wait for the upload to complete Once delivered, the build will appear in **App Store Connect** (usually within a few minutes). ## Notes on App Store Connect accounts - Transporter uploads are tied to the **App Store Connect organization** that owns the app - If your Apple ID has access to multiple organizations, make sure you’re logged in with the account that has access to the correct app record - If Transporter reports “no suitable application record”, it usually means: - The Apple ID does not have access to the app’s App Store Connect account, or - The app exists under a different organization If you hit this, contact us before retrying. ## Summary - Build and sign using the files provided by AppInChina - Export an IPA from Xcode - Upload via Apple Transporter - Manage versions, TestFlight, and submissions in App Store Connect If you run into issues, see **[Troubleshooting and Required Screenshots](./troubleshooting-screenshots.md)**. --- If you encounter issues exporting or uploading your iOS distribution build, please provide the screenshots below. They help us verify **signing**, **export configuration**, and **Transporter behavior**. ## A) Signing configuration (critical) ### 1) Xcode — Signing & Capabilities (Release / Distribution) Capture: - Xcode → Project → Target → **Signing & Capabilities** - **Release** configuration selected Must show clearly: - Bundle Identifier - Team - Signing certificate (Apple Distribution) - Selected **Distribution provisioning profile** - “Automatically manage signing” setting Why this matters: confirms the app is signed with the correct team, certificate, and provisioning profile. ### 2) Xcode — Build Settings (Code Signing) Capture: - Xcode → Target → **Build Settings** - Filter: `Code Signing` Must show clearly: - Code Signing Identity (Release) - Provisioning Profile (Release) - Development Team Why this matters: ensures no conflicting signing settings override the intended configuration. ## B) Archive and export process ### 3) Xcode Organizer — Archive summary Capture: - Xcode → Organizer - Selected archive Must show clearly: - App name - Bundle ID - Version and build number - Archive date Why this matters: verifies the archive was created correctly and matches the intended app. ### 4) Xcode — Distribution method selection Capture screens from the **Distribute App** flow showing: - **Custom** selected - **App Store Connect** selected - **Export** selected (not Upload) Why this matters: confirms the correct export path for Transporter. ## C) Transporter upload ### 5) Transporter — App loaded screen Capture Transporter after the IPA is added. Must show clearly: - IPA file name - App name - App Store Connect organization name shown at the top Why this matters: shows which App Store Connect context Transporter is using during upload. ### 6) Transporter — Full error message (if any) Capture the complete error dialog/panel so we can see all error text. Why this matters: Transporter errors usually pinpoint permission, bundle ID, or account mismatches. ## Notes on sensitive information - Do **not** share passwords, API keys, or private keys - Do **not** share certificate or provisioning profile files as screenshots - Screenshots may include app names, bundle IDs, and version numbers (this is OK) ## Minimum required screenshots (if time is limited) If you can’t provide everything, please send at least: 1. Signing & Capabilities (Release) 2. Organizer archive summary 3. Transporter error message This set is usually sufficient for initial diagnosis. ---