How often should you ship updates?

Ask five indie developers how often to ship and you'll get five confident answers, most of them superstition. The honest answer has less to do with ranking algorithms than with policy deadlines, crash math, and what you can keep doing without dreading it. Here's what update cadence changes — and what it doesn't.

Start by discarding the ranking myth

The most common reason developers ship on a schedule is fear: "the algorithm rewards fresh apps." Neither Apple nor Google publishes ranking factors, and the claim that update frequency itself boosts search position is folklore repeated until it sounds like documentation. Don't build your calendar on it.

What's verifiably true is quieter: both stores show recency to shoppers. Google Play prints an "Updated on" date in the listing's About section; the App Store stamps a date on your What's New entry and keeps the version history a tap away. A visitor deciding between you and a competitor can see that one of you last shipped this month and the other in 2024 — and a stale date reads as "the developer left." Recency earns you conversion through trust, not through a mystical ranking multiplier. That distinction matters, because it means an empty update shipped to look alive buys you nothing a listing refresh wouldn't — and costs you a trip through review.

The floor is set by policy, not motivation

Whatever cadence you choose, there's a minimum you don't get to choose. Two policies set it.

Apple removes abandoned apps. Under the App Store Improvements process, an app that hasn't been updated in three years and has effectively no downloads over a rolling twelve months gets an email: ship an update within 90 days or the app comes off the store. (People who already installed it keep it.) If your app has real downloads you'll likely never see this email — but "I finished it, it's done" is not a state Apple recognizes forever.

Google moves the floor every year. Play requires app updates to target an Android API level within one year of the latest release, and existing apps that fall too far behind stop being shown to new users on newer devices. The current instance of that rule: existing apps must target Android 15 (API level 35) by August 31, 2026, or become invisible to most of the market's new phones. In practice, Android demands roughly one rebuild a year from every app that wants to keep selling — even one in pure maintenance mode.

So the real minimum is one to two maintenance releases a year, forced by platforms rather than ambition. Budget them like rent.

What shipping smaller, more often buys you

Above that floor, the argument for frequency isn't marketing — it's risk. The value of a short release cycle is that each release contains less. When a crash spikes the day after launch, a release with two weeks of changes has a short suspect list; a release with five months of changes is an archaeology project.

The rollout tools amplify this. iOS phased release distributes an update to automatic updaters over seven days on a fixed curve — 1%, 2%, 5%, 10%, 20%, 50%, then everyone — and you can pause it for up to 30 days, though you can't change the percentages. Google Play's staged rollout lets you pick the percentage yourself and halt it. Pair a small release with a phased rollout and your worst bug reaches a sliver of users before you stop it. Pair a huge release with a full-send rollout and you get to write one of those apology posts.

Frequency also spreads out review risk. Every binary goes through App Review again, and while most submissions clear in under a day, the tail is real. If a quarter's worth of work rides in one binary, one rejection blocks all of it at once.

What every release costs

The case against shipping constantly is that a release has a fixed overhead no matter how small it is: a QA pass, a build, a submission, a spin of the review wheel, and release notes worth reading. On a team, that overhead disappears into the schedule. Solo, a weekly train can quietly eat a fifth of your working time in ceremony — time that isn't going into the features that would give you something worth shipping.

There's a user-side cost too. People with automatic updates off see every release as a badge and a chore, and a What's New that reads "minor improvements" three weeks in a row teaches them the badge means nothing. Update fatigue is the trust cost of shipping noise.

Pick a train, not a tempo

The cadence that works for most indie apps isn't "ship when it's ready" (nothing is ever ready) or "ship every Friday" (you'll hate your life by October). It's a release train: a fixed interval — every two to four weeks in active development, quarterly plus the policy rebuilds in maintenance — where the train leaves on schedule with whatever's merged. Features that miss it ride the next one. That single rule kills the death march, because missing the train costs two weeks, not a launch.

Keep a hotfix lane outside the train for crashes — that's what expedited review requests are for, used sparingly. And decouple marketing from binaries entirely: your screenshots, description, promotional text, and seasonal copy can all change without shipping a build, with no review risk to your working release. The healthiest setups we see run two clocks — a binary that ships monthly, and a listing that iterates whenever there's something to say.

The update that skips the queue

The listing-side clock is the one ShotCanvas runs: design your screenshot set once, re-render variants in minutes, generate the metadata, and publish straight to App Store Connect and Google Play — no build, no binary review, no waiting for the next train. Your app can ship monthly while your store page stays as fresh as this morning.