App Ops Desk · Issue #6

TestFlight green is not App Store green

Solo founders lose days when a build that “worked in TestFlight” dies at Connect. The trap is treating one green status as a universal ship certificate.

Read time: 6 min Release process Pairs with Issues #0 and #5

One action this week: For your next candidate build, write three separate checkboxes before you celebrate:

Uploaded / processing completed
TestFlight install + critical-path smoke on the archive build
App Store / release-review readiness (metadata freeze, privacy facts, export answers, screenshots)

If any box is blank, the build is not “shipped.”

Three different greens

Upload/processing green — Connect accepted the binary package and finished processing.
TestFlight green — testers can install; maybe external testing cleared the beta review gate.
App Store green — the version is ready for customers under current metadata, policy, and review rules.

These are related. They are not interchangeable.

Common false-confidence failures

Assuming TestFlight install proves the next archive is fine forever (toolchain may change — Issue #5)
Smoking only a Debug run, never the archive build testers actually get
Leaving privacy/nutrition/export answers “for later” because TF already works
Changing metadata after the binary is “done,” then blaming review instead of freeze discipline (Issue #3)
Treating external TestFlight review as a full App Store rehearsal
No last-known-good marker when TF goes red (Issue #4)

A practical release ladder

Identity first: marketing version, build number, git SHA, Xcode version recorded
Archive smoke: launch, core action, paywall/account path on the archived binary
Internal TF: confirm install + notes with exact build number
Store facts freeze: privacy answers, purpose strings, screenshots, what’s new
Submit only after freeze: no “one tiny metadata tweak” after the candidate is chosen
Watch processing: do not fire-and-forget before a meeting

Tester notes that prevent chaos

Build 238 (1.4.2)
Xcode: 26.x (record exact)
What changed since 231:
What to test:
Do NOT use builds: 232–237
Known issues:
Rollback build if broken: 231

“Latest” is not a build number. If two testers install different binaries, your bug reports become fiction.

When TestFlight is green and you still wait

Hold the App Store submit if:

Privacy answers changed this week and nobody re-checked them
You added an SDK and the store-facts doc is stale
Screenshots still show old UI or missing required device sizes
What’s New still says “bug fixes” for a pricing/permission change
You cannot name the last known good build in one breath

Copy/paste ship gate

Processing completed for this exact build number
Archive smoke passed on device/simulator install of that build
Internal TF notes published with exact build number
Store facts + metadata frozen
Last known good documented
Only then: submit for App Store review

Ignore list

“It installed for me” as the whole QA report
Celebrating external TF approval like a launch party
Uploading five more builds while diagnosis is still “maybe flaky”

Bottom line

TestFlight is a channel, not a certificate. Split the greens, freeze store facts before submit, and keep a named rollback build. That is boring. Boring is how solo founders stop losing release weeks.

Open the release checklist → Sections 5–7 are the ship gate. Join the App Ops Desk waitlist Weekly release ops for people who ship alone.