Skip to main content

White-label iOS app — Apple portal checklist (delegatable)

MOVED (2026-07-27): the maintained, click-by-click version of this process now lives at docs/handbook/playbooks/register-new-whitelabel-app.md (per the standing playbooks rule). Two corrections were made in the move: the provisioning-profile step was removed entirely (our builds use Xcode automatic signing — Hatter shipped without anyone creating a profile), and every step was rewritten assuming zero Apple-portal knowledge. The content below is retained for history only — follow the playbook.

Who this is for: anyone with access to our Apple Developer org (George, or an ops/support hire with the right role). No engineering knowledge needed — every step is click-by-click. The engineering half (the app build itself) is done by the agent; this checklist is ONLY the Apple-account work that Apple requires a human to do.

Source of truth for the full pipeline: hybrid/docs/claude/white-label-runbook.md. Each new client has a spec sheet there; the values you need below (brand name, bundle ID) come from that spec or the client's GitHub issue.

0. Access you need (one-time setup per person)​

  • An invitation to the Protosome Apple Developer org (developer.apple.com → membership admin invites you) with role Admin — or App Manager with "Access to Certificates, Identifiers & Profiles" enabled. Without that checkbox you can't do step 1.
  • A login for App Store Connect (appstoreconnect.apple.com) under the same org.

1. Register the bundle ID (~5 min)​

  1. Go to developer.apple.com → Account → Certificates, Identifiers & Profiles → Identifiers.
  2. Click + → choose App IDs → App → Continue.
  3. Description: the brand name (e.g. Optimal Performance). Bundle ID: Explicit → paste the ID from the client issue (e.g. io.optimalperformance.app).
  4. Capabilities — check ONLY these two:
    • ✅ HealthKit
    • ✅ Push Notifications
  5. Do NOT enable (common mistake — these are for the main Basis app only):
    • ❌ Family Controls / DeviceActivity (white-label builds strip those extensions)
    • ❌ App Groups
    • ❌ Sign in with Apple (client apps use email login)
    • ❌ Apple Pay (Stripe checkout works without it)
  6. Click Continue → Register. Done — one bundle ID per client, never the .DeviceActivityMonitorExtension / .DeviceActivityShield / .IntentHandler variants.

2. Provisioning profile (~5 min)​

  1. Same portal → Profiles → +.
  2. Choose App Store Connect (under Distribution) → Continue.
  3. Select the bundle ID you just registered → Continue.
  4. Select the existing Apple Distribution certificate (already in the org — do not create a new one; if none is listed, stop and ping engineering) → Continue.
  5. Name it <brand> App Store (e.g. Optimal Performance App Store) → Generate. No need to download — the build machine fetches it by name.

3. Create the App Store Connect record (~10 min)​

  1. Go to appstoreconnect.apple.com → My Apps → + → New App.
  2. Fill in:
    • Platforms: iOS only
    • Name: the brand's App Store display name (from the spec sheet)
    • Primary language: English (U.S.)
    • Bundle ID: pick the one from step 1 from the dropdown
    • SKU: <brand>-ios (e.g. optimalperformance-ios)
    • User Access: Full Access
  3. In the new app's App Information: set the category (Health & Fitness) and the Privacy Policy URL (provided in the client issue — it must be live before submission).
  4. Age rating questionnaire: answer all "None" except Medical/Treatment Information → Infrequent/Mild → results in a 12+/13+ rating (matches the Basis app).

4. Tell the agent you're done​

Comment on the client's GitHub issue (e.g. "#605 — Apple steps done: bundle ID, profile, ASC record created"). The agent takes it from there: builds the signed IPA, and the final upload/submission runs per the runbook's App Store Connect submission checklist (privacy "nutrition label" answers are pre-written there — Data Collected: health data YES linked to identity, payment info NO, etc.).

FAQ​

  • "It asks me to create a certificate" — don't; ping engineering. Creating duplicate distribution certificates can invalidate other apps' signing.
  • "Should I enable more capabilities to be safe?" — no. Extra capabilities trigger extra Apple review questions and approval delays (Family Controls alone adds weeks).
  • "The client wants Apple Pay" — that's a later add (merchant.io.<brand>.app); launch without it.