From Template to App Store: Shipping the SwiftUI Template

The gap between "runs in the simulator" and "live on the App Store" is where most first iOS launches stall — not on code, but on the dozen identifiers and account records that all have to agree with each other. The SwiftUI template gets you a working app immediately; this is the checklist for the last mile, drawn from what actually trips people up.

The one rule that prevents most pain: make the Bundle ID agree everywhere

In-app purchases fail silently when identifiers don't match. Your Bundle ID has to be identical in three places:

1. Xcode — the target's PRODUCT_BUNDLE_IDENTIFIER.
2. App Store Connect — the app record.
3. RevenueCat — the app configured in your RevenueCat project.

The template ships with a placeholder bundle identifier; the first pre-flight step is replacing it with your own reverse-DNS identifier in all three. If purchases "don't load" later, this mismatch is the first thing to check.

Pre-flight checklist

Before you archive:

• Apple Developer paid account — required for TestFlight and sandbox purchase testing.
• App Store Connect app record created, Bundle ID matching Xcode and RevenueCat.
• StoreKit products created in App Store Connect — an in-app purchase won't load until its product exists on Apple's side. Create your subscription/product IDs and mirror them in RevenueCat's offerings.
• Supabase configured — your project URL and keys in the template's config, so auth and the backend point at your project, not the placeholder.
• RevenueCat key set correctly — and mind this gotcha: for TestFlight and App Store builds, REVENUECAT_IOS_KEY must be the App Store key from RevenueCat, not a sandbox/other key. The wrong key is a common reason purchases work in dev and break in TestFlight.
• App icons and display name replaced.
• Sign in with Apple — if you offer social login, Apple requires Sign in with Apple alongside other providers; the template includes it, but confirm it's enabled on your app record.

Archive and upload to TestFlight

With pre-flight done, the release path is standard Xcode:

1. Select a real Release team and Any iOS Device as the destination.
2. Product → Archive — this builds the release archive and opens the Organizer.
3. In Organizer, select the archive → Distribute App → App Store Connect → Upload.
4. In App Store Connect → your app → TestFlight, wait for processing to finish, then resolve any compliance prompts (export compliance, etc.).

Install the TestFlight build on a real device and run a sandbox purchase end to end before you think about review. This is the moment the Bundle ID / product ID / RevenueCat-key chain either all lines up or doesn't.

Before you hit "Submit for Review"

App Store review rejects on predictable things. Have these ready:

• App Privacy labels — declare what you collect (auth email, any analytics/crash data). Required before submission.
• A working demo account — if your app is behind a login, reviewers need credentials to get in, or they'll reject for "couldn't access the app."
• Restore Purchases — Apple requires a visible restore path for non-consumable/subscription apps. The template includes it; make sure it's reachable from your paywall or settings.
• Purchases must actually work in review — reviewers test on a sandbox account; if your products aren't approved/available, the purchase fails and so does review.

The honest timeline

The template removes the engineering from shipping — auth, the paywall, the RevenueCat entitlement model, settings, and crash reporting are built. What's left is Apple's process: account setup, identifier alignment, and a review queue measured in days, not minutes. Budget for the review cycle, and don't leave the Bundle ID alignment or the App Store RevenueCat key to the last hour.

The App Store release docs list every placeholder to replace and walk the archive-to-TestFlight flow step by step; the configuration docs cover the Supabase and RevenueCat setup.