Update to a new build
When the server has a newer version of the app, a button appears in the top bar. Tap it and the app reloads onto the new build.
Why you would use it
An installed app serves its cached copy of itself. Without this, a deploy would never reach a phone that keeps the app open for days — and swapping scripts under a live session mid-turn would be worse.
How to use it
Leave the app open, or bring it back to the foreground. The check runs on every return to the foreground.
When the new build has finished installing behind the running one, the update button (
#update-ready) appears in the top bar, right of the tabs.
Tap it. The app reloads on the new version.
In the app on app.v-code.dev the login, box and pair screens cover the top bar,
so the same button shows on that sheet too, as Update ready — reload
(#rs-update).
What you see
- A circular-arrow button in the top bar. Its label and title are
Update ready — reload. It is hidden until a build is waiting. - It stays until you tap it. It does not cover the transcript and it does not time out.
- Tapping it reloads the page once, on the new build.
Limits and known gaps
- The button only appears when a service worker is already controlling the page, so a first-ever visit installs silently, with no button and no reload.
- The app does not update itself. Nothing swaps under a running turn.
- In dev (
VCODE_DEV_RELOAD=1) there is no service worker at all — any worker a previous production visit left behind is unregistered — so there is no update button. See dev-auto-reload. - An operator who ships a shell change without bumping
VERSIONinpublic/sw.jsnever reaches installed phones, restart or not.
Related
- open-the-app-offline — the cache the update replaces
- dev-auto-reload — the development equivalent
- update-the-install — the operator's half: what puts the new build on the server
- install-on-a-phone — the install that makes the button possible