Mobile app release flow
Code review, build, beta testing, app store submission, and rollout.
Mobile releases follow a different rhythm than web deployments. You build once, submit to the app store, wait for review, then push the same binary to millions of devices at once. There's no canary rollout or blue-green deploy — your safety gate is beta testing on TestFlight and Google Play Beta before submission.
This diagram maps the entire flow: code merge, iOS and Android builds, smoke testing on beta, app-store submission and review, production release, and the crash-rate monitoring that tells you whether to roll back fast.
When to use this template
- Mobile release SOP — annotate each gate with your team's specific acceptance criteria: "QA sign-off required", "Submit only on Tuesday", "Rollback if crash rate >3% within 1 hour."
- Release retrospectives — compare your actual release against this diagram to find process bottlenecks. Did review take longer than expected? Did TestFlight testing catch enough edge cases?
- Onboarding new developers — show this diagram on day 1 so new engineers understand why mobile deploys take 3 days vs. web's 10 minutes.
How to adapt it
Customize the workflow to match your CI/CD setup and release cadence:
- Specify which platforms you ship: iOS only, Android only, or both simultaneously as shown here.
- Add a pre-merge gate: "All CI tests pass" before merging to the release branch, if your team's CI isn't already blocking bad code.
- Expand QA smoke tests to include platform-specific checks: iOS orientation changes, Android back-button handling, both platforms' notification behavior.
- Add a delayed rollout after production release if your store supports it (both Apple and Google allow phased rollouts): release to 5% of users first, monitor for 24 hours, then expand to 100%.
The visual editor regenerates clean Mermaid code as you reshape the flow, so the final diagram drops straight into your internal mobile-dev wiki.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Merge to release branch] --> B[Build iOS + Android]
B --> C{Build succeeds?}
C -->|No| D[Alert team, fix build]
D --> B
C -->|Yes| E[Deploy to TestFlight/Beta]
E --> F[QA smoke tests]
F --> G{Issues found?}
G -->|Yes| H[Create hotfix]
H --> B
G -->|No| I[Create store submission]
I --> J{Store approval?}
J -->|Rejected| K[Fix review comments]
K --> I
J -->|Approved| L[Release to production]
L --> M[Monitor crash rate]
M --> N{Spike detected?}
N -->|Yes| O[Rollback version]
N -->|No| P[Release complete]
Frequently asked questions
- Why do mobile app releases need a separate flow from web deployments?
- Mobile apps require app-store review (Apple App Store, Google Play), which introduces a 24–48 hour delay between submission and availability. You can't deploy incrementally like web CI/CD; the entire version either goes live at once or gets rejected. Beta testing (TestFlight, Google Play Beta) replaces canary deployments as your safety gate.
- What should QA test during beta before submitting to the app store?
- Smoke tests: launch the app, navigate to each major screen, sign in if auth is gated, and trigger a key user action (purchase, file upload, real-time sync). The goal is to catch crashes and hangs before store review. Deep feature testing happens during alpha with your engineering team; beta is your last human checkpoint before the store controls the rollout.
- What causes app-store rejections, and how do I plan for them?
- Common rejections: using private APIs (Apple), missing privacy labels, crashes on first launch, or deceptive screenshots in the store listing. Budget 1–2 rejection cycles into your release calendar. The diagram shows the hotfix loop: if rejected, fix the issues and resubmit — it's normal, not a failure.
- How do I roll back a released mobile app if a critical bug emerges?
- You cannot recall a released app like a web version — users have the version and keep using it. Instead, increment to a hotfix version (1.1.1) with the fix, submit to the store, and alert users to update. In parallel, disable the buggy features server-side (feature flags) or direct users to the web app if critical. Visual edits regenerate clean Mermaid code, so document your rollback criteria here: 'crash rate >5% triggers rollback to hotfix.'
Related templates
A/B test result analysis and rollout
Evaluate test data, check statistical significance, rollout or rollback.
Blue-green deployment strategy
Parallel environments, traffic switch, and instant rollback.
Canary deployment strategy
Roll out new versions to a small percentage of traffic, then scale up.