Appstore Push Release Build

Push the App Store release-candidate build

Produces the one binary that serves both the final TestFlight test and the App Store submission: version bump → branch → build → upload to TestFlight → commit → PR → CI → merge. TestFlight builds and App Store submissions draw from the same build pool in ASC, so the exact build the user tests is what gets attached to the version and submitted — no separate App Store archive. Submitting for review remains a manual ASC click.

Relationship to siblings: this wraps the same fastlane ios beta lane as appstore-push-testflight-build, adding the release-checklist confirmation and the MARKETING_VERSION bump. (The dormant fastlane ios release lane — a separate full-binary upload via deliver — is NOT used in this flow.)

The beta lane does the heavy lifting: verifies ship secrets (scripts/verify_release_secrets.sh), queries ASC for the next build number, bumps CURRENT_PROJECT_VERSION in project.pbxproj, archives and exports the .ipa, uploads to TestFlight, and auto-commits the pbxproj change.

Preconditions

Normally invoked from /appstore:prepare-for-release with the checklist's Phases 0–3 complete. Either way, step 1 always asks the user to confirm the checklist has been worked through — this skill bakes a binary; it must not run against unfinished release prep:

• Metadata already pushed and current (python3 scripts/translate_metadata/check_metadata.py exits 0).
• Screenshots already pushed and current (or deliberately unchanged).
• Gate green on main.

Progress checklist

Print this unchecked at the start; re-print with - [x] as each step completes.

1. Prep + version — user confirmed checklist prep and the new version number
2. Pre-flight — clean working tree, on main, up-to-date with origin
3. Branch — create u/jimmyho/claude-code/release-vX.Y.Z
4. Version bump — MARKETING_VERSION set + committed
5. Build & upload — fastlane ios beta running in background (~10–15 min)
6. Verify commit — lane auto-committed chore(release): set build number to N
7. Push — branch pushed to origin
8. PR — chore PR opened; record PR number
9. CI — wait_ci.sh running in background; re-invoked on completion
10. Merge — squash-merge; branch cleaned up

Recipe

1. Confirm prep + version number — always prompt, never assume

Read the current value:

grep MARKETING_VERSION simple-recurring-budgets.xcodeproj/project.pbxproj | head -2

Then ask the user (one AskUserQuestion call, three questions):

1. "Have you worked through the release checklist — /appstore:prepare-for-release, or manually through docs/app-store-release-checklist.md Phases 0–3?" If an in-flight snapshot exists in releases/, cite its state alongside the question. A no (or "not sure") means stop and route to /appstore:prepare-for-release instead of building.
2. The new App Store version number, showing the current MARKETING_VERSION and, if known, the version ASC is expecting. The version is a product decision — even if the checklist snapshot already names one, confirm it here before it gets baked into a binary.
3. "Are screenshots and metadata for this release already pushed (or deliberately unchanged)?" A no means stop and finish the checklist's Phase 2 first — the binary can upload regardless, but a candidate built before the listing is final invites a mismatched submission.

2. Pre-flight

git status --porcelain
git branch --show-current
git fetch origin
git log HEAD..origin/main --oneline

• Dirty working tree: stop and ask the user to commit or stash first. (Exception: an in-flight release-checklist snapshot in releases/ is fine.)
• Not on main: stop and confirm before building a release candidate from a non-main branch.
• Behind origin/main: git pull --ff-only.

3. Create the release branch

git checkout -b u/jimmyho/claude-code/release-vX.Y.Z

4. Bump MARKETING_VERSION and commit

Update every MARKETING_VERSION = …; occurrence in simple-recurring-budgets.xcodeproj/project.pbxproj with the Edit tool (replace_all), then verify:

grep MARKETING_VERSION simple-recurring-budgets.xcodeproj/project.pbxproj

Commit it separately from the lane's build-number auto-commit so history stays legible. Write the message to tmp/commit-msg.txt with the Write tool (never heredoc):

chore(release): bump version to X.Y.Z

Co-Authored-By: <standard Claude co-author footer>

git add simple-recurring-budgets.xcodeproj/project.pbxproj
git commit -F tmp/commit-msg.txt

5. Build & upload — fastlane ios beta

Run in the background (run_in_background: true):

fastlane ios beta 2>&1 | tee tmp/release-build.log

The lane (~10–15 min): verifies ship secrets → sets the real next build number from ASC → archives and exports with -allowProvisioningUpdates → uploads to TestFlight (skip_waiting_for_build_processing: true) → auto-commits chore(release): set build number to <N>.

Do not use the Monitor tool for ticks — it prompts on each re-arm. Track progress on 5-minute background sleep ticks instead (memory feedback_no_prompt_periodic_progress): launch sleep 300 in the background; on its completion, read the last 10 lines of tmp/release-build.log, report a one-line status, re-arm; stop when the fastlane task exits.

6. Verify the auto-commit

git log --oneline -3
tail -60 tmp/release-build.log

Auto-commit present: record the build number N. Proceed to step 7.

Failure branches (no auto-commit + error in the log): surface the last 80 lines and stop — the version-bump commit stays on the branch, so the lane can be re-run after the fix.

• Ship-secrets guard tripped — configure config/Secrets.local.xcconfig per CONTRIBUTING.md § B, then re-run.
• Signing failure — fastlane ios verify_auth; check the distribution cert and profile in Xcode / ASC.
• Archive failure — compiler error in the log; fix and re-run from step 5.
• Upload failure (ASC HTTP 500) — transient; wait a few minutes and re-run.

Upload succeeded but no commit (rare): stage simple-recurring-budgets.xcodeproj/project.pbxproj, read N from the file, and commit chore(release): set build number to <N> manually via tmp/commit-msg.txt.

7–10. Push, PR, CI, merge

Same flow as appstore-push-testflight-build steps 5–8:

git push -u origin u/jimmyho/claude-code/release-vX.Y.Z
gh pr create --title "chore(release): vX.Y.Z — bump version and upload build <N>" --body-file tmp/pr-body.md
sleep 15
gh run list --branch u/jimmyho/claude-code/release-vX.Y.Z --limit 1 --json databaseId --jq '.[0].databaseId'
bash scripts/wait_ci.sh <run-id> <pr-number>   # run_in_background: true
gh pr merge <pr-number> --squash --delete-branch
git checkout main && git pull --ff-only
git branch -D u/jimmyho/claude-code/release-vX.Y.Z
git fetch --prune

PR body (via tmp/pr-body.md, Write tool): What = version bump to X.Y.Z + release-candidate build uploaded to TestFlight for App Store submission; cross-cutting concerns section all N/A (build infrastructure only).

Done — hand back to the checklist

Report: "Release candidate build (vX.Y.Z) is uploaded and the PR is merged. Apple takes ~30 min to process it; then install build via TestFlight for the final manual test (Settings must show vX.Y.Z () with no 'Debug' badge). That exact build is what you attach to the version in ASC and submit for review — nothing has been submitted yet." If running under /appstore:prepare-for-release, mark the corresponding snapshot items and continue the checklist.