Shipping updates
How a change reaches people who already installed your app, and the one distinction that decides which route it takes.
Once someone has your app installed, changes reach them one of two ways. Which one depends on a single question: did the change alter what the app is made of, or only what it does?
The two routes
| Change | Route | What the person does |
|---|---|---|
| Screens, layout, styling, copy, business logic, bug fixes | Delivered to the installed app | Nothing. Next time they open it |
| A new device capability (camera, maps, notifications), a platform upgrade, a new permission | A new build | Installs it again |
The first route is the reason most fixes reach people the same day, with no reinstall and no store review.
How the fast route works
Installed apps check for an update every time they are opened. If there is one that matches their version of the app, it is downloaded and used. That covers the large majority of ordinary changes.
Today this is driven from the AI editor path rather than from the dashboard. If you are working entirely in the browser, changes reach people through a new build. See Use an AI editor.
Why the second route exists
An update on the fast route only replaces the app's logic, not its foundations. If new logic expects a capability the installed app does not physically contain, for example the camera in an app that never had camera support, the app opens fine and then crashes the moment someone reaches that screen.
That is the worst kind of failure: it happens on someone's phone, after install, where no build check can see it. So a change that adds a capability requires a new build, and the two are kept apart deliberately.
If you are unsure which kind of change you made, ask in the build chat.
Practical guidance
- Fixing a bug, changing copy, adjusting a screen? Fast route. Ship it
- Adding a feature that uses the camera, location, maps, or notifications for the first time? New build. Plan for people to reinstall
- On the Play Store? A new build means a new submission and a new review
Rolling back
If an update turns out to be wrong, fix forward rather than trying to unship it. The next update reaches people the same way the bad one did.
For changes you have not shipped yet, Keep or Discard lets you back out before anyone sees it.
Testing an update
Test on a phone that already has the previous version installed, not a fresh one. Updates break differently than first installs: stale local data, an old cached screen, a saved session from the previous version. A fresh install tests none of that.