The Update Ceremony

Never half an app. All of it, verified, or nothing.

Written by Ivan Ivanov - Business Mechanic (consultant)

How Apple, Android, Chrome and the car industry update software without ever breaking it — and the ceremony PhotoCashFlow adopts for every update it ships.

≈ 9 min

The six principles

Half an update is worse than none

A modern app is not one file. It is hundreds of files that agree with each other: the screen agrees with the engine, the engine agrees with the database, the database agrees with the sound files. When an update replaces some of those files and not the others — an old screen running on a new engine, half a cache swapped under a live program — the program does not slow down. It starts to lie. Doors that work in the morning stop working after lunch. A voice loads once and never speaks again. Nothing is exactly broken, and nothing is exactly right.

Engineers call this version skew, and it is not a code problem. It is a ceremony problem: pieces swapped one by one, in place, while the machine is running. Every serious engineering organization on Earth banned that ceremony years ago. This article is about the one they replaced it with.

One machine, five names

Strip the brands off Apple, Android, Chrome, Expo and the automotive standard Uptane, and the same machine falls out — in four moves.

Download beside — never over the running version

Verify everything against one signed list

Wait for the boundary — nothing switches mid-work

Flip once — then prove it, or roll back

Files replaced in place: 0

The new version is written next to the running one — into an idle partition, a fresh cache, a staging folder. The list is checked first; then every file is checked against the list; then, in the strictest systems, what was written is read back and checked again. The switch is a single flip, not a migration — and the new version starts on probation.

How the giants actually do it

Different industries, different decades — one answer, each piece of it verifiable in the maker's own documentation.

Five systems, one machine PRIMARY SOURCES

Apple — iPhone & iPad Every byte of the system is hashed into a single seal, checked by the bootloader before the system may start. An update prepares a new sealed snapshot beside the old one — and the volume holding the user's own data is never even mounted during an update. Sealed system volume

Android & ChromeOS The device carries two copies of the system and runs from one. Updates write only to the idle copy, marked unbootable while written. The new copy must boot and pass an integrity check — before any app code runs — before it earns the mark “successful”. A/B slots

Chrome Every update is one instrumented session: check, download, report back. The browser tells the update servers whether it succeeded, which addresses it used, and which error codes it met. Fleet update health is measured, not assumed. Omaha protocol

Expo & CodePush An update is one manifest plus the files it lists, each with its cryptographic hash. The signature is verified on the device after download, before anything applies. An update that crashes before the app confirms it is healthy rolls back on the next start — automatically. Signed manifest

Uptane — automotive Signing is split into four roles with separate keys, and two independent repositories must agree on what a given car installs. The founding assumption: something will be compromised one day — so one compromise must never reach the fleet. Four keys, two witnesses

One honesty note: Tesla is widely described as the pioneer of updating cars over the air, and its cars plainly receive staged updates. But Tesla publishes no engineering documentation of its internal update design — so nothing in this article rests on Tesla. The automotive principles here stand on Uptane and on Android: documents anyone can read.

The principles, in one breath

Six rules. Every system in this article obeys all six.

PRINCIPLE 1

Never write over the running version

The old version is the lifeboat. It stays untouched until its replacement has completely arrived.

PRINCIPLE 2

One list describes the whole release

Every file, its size, its fingerprint — signed once. A file that is not on the list does not exist. A file that fails the list kills the update.

PRINCIPLE 3

Verify — then verify what you wrote

Check the signature. Check every byte on the way in. Then read it back and check it again. Downloaded is not a synonym for correct.

PRINCIPLE 4

Switch once, at a boundary

Not file by file, not mid-task. One flip, at a moment the running work cannot straddle — a reboot, a relaunch, a space between customers.

PRINCIPLE 5

Probation is real

The new version is a guest until it marks itself healthy. No mark — no permanence. The old version returns by itself.

PRINCIPLE 6

Roll forward, never scramble back

When a release goes bad, the cure is a new release that contains the last good version. The fleet always moves forward — even when forward means “back to what worked”.

You can't drive during install. So install waits until you park.

Cars refuse to install updates while driving. Phones demand battery, and a charger, before they prepare one. The update serves the work — never the other way round. For a tool that sells, the boundary is not a reboot. It is the space between two customers.

What PhotoCashFlow adopts

Copied piece for piece from the systems above — scaled to an app that lives on a tablet, and honest about what a tablet browser can and cannot do.

GATE 1

Between customers, or not at all

Downloads happen silently, in the background, into a store the running app never reads. The switch is offered only when no sale is open — one tap, between customers, behind a progress display that counts only bytes already verified.

Progress = verified bytes only

GATE 2

Probation: prove it in seconds

After the switch, the new version must open cleanly, confirm its own build number matches the engine serving it, and check its database — or the previous version returns automatically. No meeting, no decision, no stranded tablet.

Healthy — or rolled back

GATE 3

Recovery rolls forward

A bad release is killed from the server: the channel republishes the last good build as the newest release, and every tablet updates forward to safety through the same tested path.

One action stops a bad release, fleet-wide

The progress display speaks the giants' vocabulary, in phases: Checking → Downloading → Verifying → Ready — applies between customers → Applying → Done. Because the signed list states the total size up front, the bar is determinate — real bytes, verified — and the time estimate is shown as a range, the way ChromeOS and Android show phases rather than fake a countdown. A file counts only after its fingerprint checks out; downloaded-but-unverified is not progress.

And the honest limits, stated rather than hidden. On an iPad, a web app cannot download while it is closed — downloads happen while the app is open and idle. Safari gives web apps no battery reading, so the power rule is a human ritual instead of an automated gate: plugged in, start of day, before the first customer. A system that states its limits can be trusted inside them.

What this article does not claim

No percentages. None of the makers publishes success rates for these update systems; the documented case is qualitative — fewer bricked devices, fewer reflashes, fewer warranty replacements. Anyone who quotes you a precise success rate for A/B updates is inventing it.

Nor that the ceremony is free. Keeping two versions, verifying every byte, and holding a release at the gate costs storage, bandwidth and patience. The giants pay it because the alternative — a half-updated machine in front of a paying customer — costs more.

Sources

Never half.

From here on, every PhotoCashFlow update is a ceremony, not a shuffle: beside, verified, gated, proven. The amateur way is cheaper — until the day it costs a customer.