Mobile Release

Mobile release

Usage: $mobile-release [optional release context] (Claude Code: /mobile-release).

Carry a release through preparation, verification, shipping, and both stores. A release request authorizes the necessary store writes, build/submission jobs, and push to main. Naming individual steps — bump the version, write the release notes, cut the build — still requests the whole release: yarn bump exists only to cut one, and the release workflow is gated on a bumped-but-untagged version, so a bump that is not shipped strands the release half-done. Narrow the scope only on an explicit stop signal such as “prepare only”, “do not publish yet”, or “just the notes”; without one, carry through to both stores rather than stopping to confirm. Creating this skill does not invoke it. Do not ask again for authorization already given. Review concrete plans before recording approvals; never bypass the repository's release gates.

Establish release state

Locate the repository with git rev-parse --show-toplevel. Read root and mobile AGENTS.md, mobile/docs/app-store-localization.md, mobile/scripts/app-store-release.sh, mobile/scripts/play-release.sh, mobile/eas.json, and .github/workflows/deploy.yml. Run package commands inside mobile/; keep scratch artifacts in mobile/tmp/. Discover installed gh, asc, and the workflow's pinned EAS CLI capabilities with --help rather than assuming newer commands exist.

Inspect branch, staged and unstaged changes, and remote state. Fetch origin and tags. Preserve unrelated work; release only reviewed changes. Bring the release base up to date before preparing notes. Do not push a version bump until its store staging receipt is ready.

Find the previous reachable mobile tag using git describe --tags --match 'mobile-v*' --abbrev=0 HEAD. Compare that tag to the candidate release using mobile-scoped git log and git diff; inspect release workflow changes too. If no tag exists, label this a first release and inspect available mobile history. Tags from other packages are not a baseline.

Check GitHub release runs, EAS builds/submissions, App Store Connect versions, and Google Play tracks. A mobile-v<version> tag proves both EAS builds finished and their submissions completed, because the workflow waits for them; tags up to mobile-v1.20260912.48 were cut with --no-wait and only prove kickoff. A tag does not prove either store is live. Report any difference between the tag baseline and the last live version; include still-unreleased changes in store notes when needed.

If the current version is untagged or has incomplete jobs, determine whether it is an existing release to resume before bumping. Do not create another version merely to retry. Do not edit an Apple version already in review; report the pending review as the blocker to a new release.

Verify credentials and access without printing secrets. Check the effective Android submission profile, Google Play application identity, service-account access, production track, release status, and review settings. submit.production.android currently targets production with completed release status; verify service-account access separately because the profile does not contain a local key path. Resolve needed non-secret configuration within release scope, or identify the precise missing access. Never substitute a testing track for the requested production release.

Check the iOS scene life cycle before an iOS store build. UIKit requires the scene-based life cycle for apps built with the iOS 27 SDK (Xcode 27), and Expo adopted it in expo 58.0.0-preview.0 (expo/expo#46733). Apps on an earlier SDK fail to launch when built with that SDK (expo/expo#46663). Read the expo version in mobile/package.json, and confirm which Xcode the production EAS build will use: mobile/eas.json pins no iOS image, so EAS picks its default image for the SDK. If that build would use the iOS 27 SDK or newer while expo is below 58, stop before bumping and report the SDK upgrade as the release blocker. Do not hand-write UIApplicationSceneManifest into app.json: without the matching delegate adoption it fails worse, and prebuild reverts it. After an SDK upgrade, confirm a cold-launch native iOS log no longer reports UIScene lifecycle will soon be required.

Summarize and bump

Write concise user-facing release notes grounded in the inspected diff: features, fixes, and material behavior changes. Omit internal churn and unsupported claims. Show the baseline tag/SHA and candidate SHA, and keep the summary for the final report and commit context.

For a new release, run yarn bump once. Use the version it emits: this repository uses 1.YYYYMMDD.build, not a conventional patch increment. Inspect all generated changes, including native versions when present. For a resumed release, retain its version and completed preparation.

Fill every metadata/version/<version>/<locale>.json whatsNew using the same factual summary, translated using shipped terminology and metadata/store-locales.json. Preserve stable listing copy unless the release warrants a change. Keep template whatsNew blank. Fill the Android changelog emitted by the bump script, if present; inspect the actual script/output rather than assuming the legacy fastlane directory exists or is uploaded by EAS. Ensure the same notes are applied to the Google Play release through available authenticated tooling.

EAS uses remote native build numbers with auto-increment. Inspect the actual resulting iOS build number and Android version code; do not assume they equal the local suffix when selecting builds or attaching Android notes.

Prepare Google Play listing copy

Set GOOGLE_PLAY_SERVICE_ACCOUNT to the local JSON key path used by EAS Submit, without printing the key or token. Run yarn play:baseline, inspect tmp/play-baseline/baseline.json, and record the actual locale coverage. Do not assume the existing listing is English-only. Baseline reads create and delete an uncommitted edit; avoid concurrent Play edits with that account.

Run yarn play:generate after the bump and baseline review. It derives metadata/play/<locale>.json from canonical app-info/version metadata, using metadata/play-source/bg.json and fa.json for the languages Apple cannot offer. The result must cover all 16 Play locales / 13 runtime languages. Regenerate after any canonical listing change. Keep the baseline and credentials ignored; commit only the generated public copy and its canonical inputs.

Stage Apple listing before pushing

Run yarn format:check, yarn test, and yarn metadata:validate. Fix release-related failures and inspect any lint autofixes. Build and validate screenshots using yarn screenshots:build and yarn screenshots:validate; use the public demo sources, never a private ledger.

Follow the current release helper and localization guide. The required order is below; replace <version> with the actual target. Repeating the version is the helper's confirmation mechanism, not a reason to solicit authorization again.

./scripts/app-store-release.sh create <version> <version>
./scripts/app-store-release.sh plan <version>
# Inspect metadata/plan.md, metadata/keywords-plan.md, and screenshots/index.html
# under mobile/.asc/releases/<version>/; visually inspect generated screenshots.
./scripts/app-store-release.sh approve <version> <version>
./scripts/app-store-release.sh apply-metadata <version> <version>
./scripts/app-store-release.sh plan-screenshots <version>
# Inspect the separate screenshot replacement/order plan before applying.
./scripts/app-store-release.sh apply-screenshots <version> <version>
./scripts/app-store-release.sh verify <version>
yarn store:staging-check

Inspect helper assumptions before using it (including its metadata-copy source and automatic release setting). The verification writes metadata/releases/<version>.json bound to the exact listing inputs. Never fabricate or hand-edit that receipt. If any bound input changes afterward, repeat the affected plan/review/apply and parity verification. Keep .asc/, generated screenshots, credentials, and raw remote responses out of Git.

If authorization is actually missing, finish all possible local preparation first, present the target version, notes, intended store actions, and available plans, then ask only for the missing scope. Cite the precise applicable instruction if it requires additional human approval. Do not claim to have obtained operator approval that was never given.