From atum-stack-mobile
Mobile app store deployment coordination pattern library for iOS and Android — end-to-end release workflow from dev build to public listing. Covers the complete pipeline: version management (semver + build number auto-increment), feature flags for staged rollouts, release branch strategies (git flow for mobile), internal QA on TestFlight + Play Console Internal Testing, beta distribution (TestFlight External + Play Console Closed Testing), final App Store / Play Store submission with Apple review + Google Play review processes, phased rollout strategies (iOS phased release, Play Console staged rollout), hotfix flows (iOS expedited review vs EAS Update OTA, Play Console halted rollout), and cross-platform release synchronization. Use when planning a mobile release, coordinating iOS + Android releases in parallel, handling hotfixes, or setting up a mobile CI/CD pipeline. Orchestrates the specialized deploy-eas, deploy-app-store, and deploy-play-store skills (in atum-workflows) into a single release workflow that ATUM agency can repeat on every mobile client project.
npx claudepluginhub arnwaldn/atum-plugins-collection --plugin atum-stack-mobileThis skill uses the workspace's default tool permissions.
Ce skill est le **chef d'orchestre** des 3 skills spécialisés (`deploy-eas`, `deploy-app-store`, `deploy-play-store` dans `atum-workflows`). Il fournit le **workflow complet** d'une release mobile en production, pas les détails techniques des outils.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
Ce skill est le chef d'orchestre des 3 skills spécialisés (deploy-eas, deploy-app-store, deploy-play-store dans atum-workflows). Il fournit le workflow complet d'une release mobile en production, pas les détails techniques des outils.
À lire avant de commencer : ce skill + les 3 skills de atum-workflows ci-dessus.
┌─────────────────────────────────────────────────────────────┐
│ 1. DEV │
│ git push → CI → EAS Build dev profile → TestFlight internal │
│ Play Console internal │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 2. STAGING │
│ PR merge main → EAS Build preview → TestFlight external │
│ Play Closed Testing │
│ Beta testers (50-500) │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 3. PRODUCTION │
│ Git tag vX.Y.Z → EAS Build production → EAS Submit │
│ App Store Review (1-2d) │
│ Play Store Review (1-3d) │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 4. ROLLOUT │
│ iOS phased release 7 days (1→2→5→10→20→50→100%) │
│ Play Console staged rollout 10%→50%→100% │
│ Monitor crashes via Crashlytics / Sentry │
└─────────────────────────────────────────────────────────────┘
1.0.0 — Major (breaking UI change)1.1.0 — Minor (new feature)1.0.1 — Patch (bug fix)Auto-incrémenté par EAS (autoIncrement: true dans eas.json) ou via cli.appVersionSource: "remote".
Règle Apple : build number strictement croissant pour chaque upload (même si même version marketing).
Règle Play : versionCode strictement croissant, versionName libre.
Garder la même version marketing sur les deux stores. Incrémenter au même moment.
// app.json (Expo)
{
"expo": {
"version": "1.2.0",
"ios": {
"buildNumber": "1.2.0"
},
"android": {
"versionCode": 42
}
}
}
main ─────●────────────●─────────────●──── (production releases)
│ │ │
release/1.2.0 │ ●─────●───┤ │
│ │ │ │ │
develop ──●──┴──●──●──●───●───●─────●───●──── (integration)
│ │ │
feature/x ●────● │ │
│ │
hotfix/y ●─────● (critical bug fixes)
develop — intégration continue, déclenche TestFlight internal + Play Internalrelease/X.Y.Z — freeze + QA beta, déclenche TestFlight external + Play Closed Testingmain — production uniquement, tag vX.Y.Z déclenche EAS Submithotfix/Y — urgent fix, branché depuis main, merge dans main + developPour les équipes de 1-3 devs : juste main + feature branches. Les tags vX.Y.Z déclenchent les submissions.
Avant d'envoyer le build en review — commun iOS + Android :
version + buildNumber / versionCoderelease/1.2.0 dans main via PRv1.2.0 sur maineas build --profile production --platform alleas submit --profile production --platform ios --latest → upload App Store Connecteas submit --profile production --platform android --latest → upload Play ConsolePour un bug critique (crash, data loss, security) :
hotfix/1.2.1 depuis mainSi le fix est 100 % JavaScript (pas de natif modifié) :
eas update --branch production --message "Fix login crash"
Les users reçoivent la update au prochain lancement. Pas de review Apple. Bypass du review uniquement pour des fixes JS, et dans les limites des guidelines (4.1 Copycats, 3.2.2 Acceptable business model, etc.).
Si bug détecté pendant le rollout :
Recommandation agency : Release train pour les clients, Ship when ready pour les projets internes.
Au lieu de releaser un feature à 100 % des users au même moment :
// Via PostHog, LaunchDarkly, Statsig, ou un simple JSON remote
const enableNewCheckout = useFeatureFlag('new-checkout')
return enableNewCheckout ? <NewCheckout /> : <OldCheckout />
deploy-eas (dans atum-workflows)deploy-app-store (dans atum-workflows)deploy-play-store (dans atum-workflows)expo-expert (dans atum-stack-mobile)swift-expert (dans atum-stack-mobile)kotlin-expert (dans atum-stack-mobile)flutter-dart-expert (dans atum-stack-mobile)security-reviewer