app-release

App Release (iOS / watchOS → TestFlight / App Store)

Drive an iOS/watchOS app from "production path unstarted" to a Distribution-signed

build processing in TestFlight. The hard part is not any single step — it is that

the release path spans three disconnected web portals (Apple Developer, App Store

Connect, CloudKit Dashboard) plus CLI signing arcana, and **each gate hides a silent

failure discoverable only after the previous one passes.** Treat the whole thing as

an airlock checklist: each gate must verifiably seal before the next opens.

When to use

Releasing/publishing/shipping an iOS or watchOS app; getting a build to TestFlight;

archiving + uploading; deploying CloudKit schema to Production; filling App Privacy

or export compliance; distribution signing; or debugging an Apple upload rejection.

The gates (run in order; verify each before moving on)

Track every gate in the project's issue tracker. Do not assume a gate is closed

because a portal shows green — verify the underlying artifact.

1. Inventory the gates. List what is actually open (issue tracker, or derive

from the steps below). Distinguish gates that block TestFlight from gates that

block App Store submission — they are different.

1. CloudKit → Production (if the app uses CloudKit). Development indexes/record

types do not exist in Production until an explicit Deploy Schema Changes.

Deploy via the dashboard and verify the record type appears in the Production

environment. One-way action — confirm with the user first.

1. Export compliance. Bake ITSAppUsesNonExemptEncryption: false into every

shippable target (the app and the watch app), in the source of truth (e.g.

XcodeGen project.yml info.properties), so TestFlight never prompts per build.

1. App Privacy. Audit the code for analytics / third-party SDKs / external

networking first. If the developer cannot access user data (e.g. data lives only

in the user's private CloudKit), the honest label is Data Not Collected. Set

it in App Store Connect. Leave Publish for submission time.

1. Privacy Policy + Impressum. App Store requires a hosted privacy-policy URL;

an EU/German operator also needs an Impressum. Add pages to the product site,

deploy, paste the privacy URL into App Store Connect.

1. Signing audit. With automatic signing, Xcode mints the Distribution cert +

App Store profiles at archive/export — no manual portal work. Confirm the team

id and CODE_SIGN_STYLE: Automatic.

1. Archive. xcodebuild archive the iPhone scheme that embeds the Watch app,

-allowProvisioningUpdates. (Archive signs with Apple Development; the

Distribution cert is minted at the export step.)

1. Export + upload to TestFlight. xcodebuild -exportArchive with method

app-store-connect, automatic signing, and an App Store Connect API key.

The key must be Admin role — a Developer-role key cannot cloud-sign and fails

with "Cloud signing permission error / no iOS Distribution cert found."

1. Hand off the device test. The final TestFlight verification (install the

processed build, exercise the real feature loop on Production) is a human

on-device step. Do not claim it as done.

**Read [references/pipeline.md](references/pipeline.md) for the exact commands,

ExportOptions.plist, and verification one-liners for every gate above.**

**When any step fails with a cryptic Apple error, read

[references/gotchas.md](references/gotchas.md) first** — it catalogs the silent

failures from real releases (corrupted SwiftPM checkout, Developer-role API key,

missing CFBundleShortVersionString, iPad-orientation 90474) with the exact fix.

Guardrails (non-negotiable)

• Confirm before one-way production actions: CloudKit Deploy to Production and

App Privacy Publish. They affect shipped users / the public product page.

• Never print secret key values. Keep .p8 keys in ~/.appstoreconnect/; clean

up any temp copies after use.

• Use trash, never rm.
• Drive logged-in portals via browser automation; never enter Apple credentials.

Ask the user to log in once in the automation browser.

• **Leave the on-device feature-loop test and the final Publish / Submit-for-review

to the human.**

• Commit only release-related changes in focused commits; never sweep unrelated

branch WIP into a release commit.

Tooling notes

• Portal work (CloudKit Dashboard, App Store Connect, Apple Developer) is best driven

through a persistent logged-in browser (e.g. the browser-mate skill) so the user

logs in once and the session persists.

• The heavy build/sign/upload steps belong in the shell (xcodebuild), not GUI

clicking — the CLI gives real error output instead of a progress bar. Reserve

computer-use/GUI for steps that genuinely need it.

• Run long xcodebuild steps in the background and poll for ARCHIVE SUCCEEDED /

EXPORT SUCCEEDED / Upload succeeded markers.