Mobile Release
Purpose
Plan the release: store submission, versioning/build numbers, OTA updates (Expo), staged rollout, and release validation — with store publishing gated by approval.
When to Use
- For a mobile release/deployment.
- When planning OTA updates or store submission.
- Not to publish without explicit approval or a passed release gate.
Inputs
- Validated builds (
mobile-builds) and readiness (ios-readiness, android-readiness).
- Store accounts, versioning, rollout strategy.
Discovery Questions
- Store submission via EAS Submit or native tooling?
- What versioning/build-number scheme?
- OTA updates (Expo) for JS-only changes, and their limits?
- Staged rollout or full release? Rollback plan?
Responsibilities
- Plan store submission (EAS Submit / native) and versioning.
- Plan OTA updates (Expo) for eligible JS-only changes, with limits noted.
- Plan staged rollout and rollback.
- Confirm readiness (
ios-readiness, android-readiness) and run release validation (../../release-planning, Gate 7).
Required Workflow
- Confirm builds validated + readiness passed.
- Set versioning/build numbers.
- Plan submission + OTA + rollout/rollback.
- Confirm explicit approval to publish.
- Execute/handoff; verify + record.
Decision Rules
- Store publishing is outward-facing — explicit approval required (
../../../system/OPERATING_RULES.md).
- OTA suits JS-only changes; native changes need a new store build.
- Prefer staged rollout for risky releases with a rollback path.
- Don't ship on a failed gate (
../../release-planning).
Rules
- No store submission without explicit approval.
- Follow Gate 7 (
../../release-planning).
- Keep signing/store credentials secure.
Anti-Patterns
- Submitting to stores without approval.
- OTA-ing native changes.
- Full rollout of risky releases with no rollback.
- Shipping with failing readiness/tests.
Validation Checklist
Definition of Done
A recorded release plan: store submission, versioning, OTA strategy, staged rollout with rollback, and release validation (Gate 7) — with store publishing explicitly approved and verified.
Related Skills
mobile-builds, ios-readiness, android-readiness, ../../release-planning, ../../github-repository, mobile-maestro-e2e
Related Knowledge
../../../knowledge/ (release process, store accounts).
Related References
../../../references/mobile/native/ when populated.
Context Loading Guidance
- Requires: validated builds, readiness status, versioning + rollout strategy, approval.
- Does not require: unrelated screens, the full mobile skill set, unrelated references.
- May load:
../../release-planning, readiness skills, mobile-builds.
- Stop when: the release is validated and recorded (or blocked at Gate 7).
Token Efficiency Guidance
Work from build/readiness status; keep the release record to criteria, actions, outcome.
1---2name: mobile-release3description: Use to plan mobile release — store submission (EAS Submit / native), versioning, OTA updates (Expo), staged rollout, and release validation. Publishing to stores requires explicit approval; coordinates readiness.4---56# Mobile Release78## Purpose910Plan the release: store submission, versioning/build numbers, OTA updates (Expo), staged rollout, and release validation — with store publishing gated by approval.1112## When to Use1314- For a mobile release/deployment.15- When planning OTA updates or store submission.16- Not to publish without explicit approval or a passed release gate.1718## Inputs1920- Validated builds (`mobile-builds`) and readiness (`ios-readiness`, `android-readiness`).21- Store accounts, versioning, rollout strategy.2223## Discovery Questions2425- Store submission via EAS Submit or native tooling?26- What versioning/build-number scheme?27- OTA updates (Expo) for JS-only changes, and their limits?28- Staged rollout or full release? Rollback plan?2930## Responsibilities3132- Plan **store submission** (EAS Submit / native) and **versioning**.33- Plan **OTA updates** (Expo) for eligible JS-only changes, with limits noted.34- Plan **staged rollout** and **rollback**.35- Confirm **readiness** (`ios-readiness`, `android-readiness`) and run **release validation** (`../../release-planning`, Gate 7).3637## Required Workflow38391. Confirm builds validated + readiness passed.402. Set versioning/build numbers.413. Plan submission + OTA + rollout/rollback.424. Confirm explicit approval to publish.435. Execute/handoff; verify + record.4445## Decision Rules4647- Store publishing is outward-facing — explicit approval required (`../../../system/OPERATING_RULES.md`).48- OTA suits JS-only changes; native changes need a new store build.49- Prefer staged rollout for risky releases with a rollback path.50- Don't ship on a failed gate (`../../release-planning`).5152## Rules5354- No store submission without explicit approval.55- Follow Gate 7 (`../../release-planning`).56- Keep signing/store credentials secure.5758## Anti-Patterns5960- Submitting to stores without approval.61- OTA-ing native changes.62- Full rollout of risky releases with no rollback.63- Shipping with failing readiness/tests.6465## Validation Checklist6667- [ ] Builds validated + readiness passed.68- [ ] Versioning/build numbers set.69- [ ] Submission + OTA + rollout/rollback planned.70- [ ] Explicit publish approval obtained.71- [ ] Release validated + recorded.7273## Definition of Done7475A recorded release plan: store submission, versioning, OTA strategy, staged rollout with rollback, and release validation (Gate 7) — with store publishing explicitly approved and verified.7677## Related Skills7879`mobile-builds`, `ios-readiness`, `android-readiness`, `../../release-planning`, `../../github-repository`, `mobile-maestro-e2e`8081## Related Knowledge8283`../../../knowledge/` (release process, store accounts).8485## Related References8687`../../../references/mobile/native/` when populated.8889## Context Loading Guidance9091- **Requires:** validated builds, readiness status, versioning + rollout strategy, approval.92- **Does not require:** unrelated screens, the full mobile skill set, unrelated references.93- **May load:** `../../release-planning`, readiness skills, `mobile-builds`.94- **Stop when:** the release is validated and recorded (or blocked at Gate 7).9596## Token Efficiency Guidance9798Work from build/readiness status; keep the release record to criteria, actions, outcome.
ahtishamshahzad