OtaKitHow often should you release a mobile app?
Weekly, every two weeks, or monthly? How store review, phased rollouts and user update behavior shape release cadence, and the two-track model that lets you ship daily without annoying users or reviewers.
Web teams deploy many times a day. Mobile teams usually release every one to four weeks. The gap is not about discipline; it is about friction. Every mobile release goes through store review, rolls out over days, and then waits for users to actually install it. So how often should you release?
The short answer: release the native app on a steady, predictable schedule, and ship everything that does not need a new binary on a separate, faster track. This guide explains why, and how to set both up.
What limits mobile release speed
| Step | Typical time | Can you speed it up? |
|---|---|---|
| Build, sign and upload | Minutes to an hour | Yes, with CI |
| App Store review | Apple says most submissions are reviewed within 24 hours; rejections add days | Only by avoiding rejections |
| Google Play review | Hours to several days, longer for new apps | Not really |
| Phased rollout | Apple’s phased release takes 7 days; Play staged rollouts are manual | Yes, but rolling out fast is riskier |
| Users installing the update | Days to weeks; some users never update | Only with forced update prompts |
The last row is the one people forget. Even if review were instant, a release reaches most active users only after a week or more of automatic updates. A bug fix that ships on Monday is still on many phones the following Monday.
Common cadences and when they fit
- Weekly. Used by large teams with release trains: whatever is merged by the cut-off ships. Great for momentum, but review and QA overhead is paid every week.
- Every two weeks. The most common choice. Enough time for meaningful changes and a proper QA pass, frequent enough that users see steady improvement.
- Monthly or slower. Fine for mature apps with little native change, or for regulated industries with heavy sign-off. Painful when something breaks.
- Whenever something is ready. Works for tiny teams, but unpredictable releases make QA, marketing and support harder to plan.
Whatever you choose, consistency matters more than frequency. A predictable schedule lets everyone plan, and keeps each release small enough to test properly.
The two-track model
In a Capacitor app, a release is two different things: the native shell (Swift, Kotlin, plugins, permissions) and the web layer (your UI and business logic). They change at very different rates, so give them different tracks.
| Native track | Web track (OTA) | |
|---|---|---|
| What ships | Plugins, permissions, Capacitor upgrades, SDK updates | Screens, copy, styles, logic, fixes |
| Cadence | Every 2–4 weeks, or only when needed | Daily, or on every merge |
| Goes through review | Yes | No, within store rules |
| Reaches active users | Over days to weeks | On their next app launch |
| Rollback | Submit another build | Re-release the previous bundle |
Many teams find that most of their changes are on the web track. The native release then becomes a small, calm event: fewer changes, less risk, easier review.
This is within the rules on both stores, as long as over-the-air updates change the web content rather than the purpose of the app. See OTA policies for the App Store and Google Play.
Setting up the web track
With OtaKit, the web track is one command after your normal build. A reasonable setup:
# on every merge to main: release to internal testers npm run build npx @otakit/cli upload --release staging # when staging looks good: promote the same bundle to everyone npx @otakit/cli release <bundleId> --channel production
Put both in CI and the web track runs itself. See automating OTA releases with GitHub Actions.
Hotfixes: the case for a fast track
The strongest argument for a separate web track is not speed on a normal day. It is the bad day. When a release breaks checkout, a store hotfix takes review time plus days of user adoption. An OTA fix reaches active users within hours, and with --force-immediate devices apply it on their next check instead of their next launch.
Keep the emergency path rare. Force-immediate reloads the app for users in the middle of what they are doing. Use it for broken payments and data loss, not for a typo. See deploying hotfixes over the air.
A cadence that works for most teams
- Native release every two to four weeks, on a fixed day, only if native code changed. Use Apple's phased release and Play's staged rollout.
- Web releases continuously, to staging on every merge and to production once or several times a week.
- Staged rollouts for large web changes, so a problem reaches a few users before everyone. See staged rollouts.
- A written hotfix procedure, so nobody improvises during an incident.
You end up with the calm of a predictable native schedule and the speed of web deployment. OtaKit has a free tier, so you can add the web track to your next release and compare.