Native Update

How long does a typo live in a shipped mobile app?

As long as the review queue takes, plus however long your users take to update, and neither of those numbers belongs to you. Meanwhile the broken screen keeps opening.

That is the problem an over-the-air channel exists to solve, and it brings a worse one with it.

A path that can replace an app's code remotely is a path somebody else would like to use.

So integrity comes first. Every bundle is signed and verified with SHA-256 and RSA-SHA256, and one that does not verify does not run.

The second requirement is the one people skip. A bad bundle has to be able to undo itself with nobody in the loop, because the person who could intervene is asleep in a different timezone.

Fail to boot twice and the native side rolls back on its own.

native-update is a Capacitor plugin on npm, and around it sits everything an update channel actually needs rather than the plugin on its own.

A release-management CLI handles bundles. It creates them, signs them and verifies them before any of them leaves the machine.

A Laravel 11 and Nova 5 backend holds apps, keys and releases behind bearer-token authentication and role-based access control, so who may publish to a channel is a question with an answer rather than a convention. A React 19 dashboard sits on top of that, itself wrapped with Capacitor for the Play Store.

Store update checks and throttle-aware review prompts live in the same plugin, because an app that needs an over-the-air path also needs to know when a real store update is waiting for it.

Documentation runs to 58 public pages, with two runnable example apps beside it, because a plugin that changes how an app boots cannot honestly be explained in a README.

That is the difference between a package you can adopt and a package you can read about.

198 tests hold it: 62 in TypeScript and 136 in Pest, with a Detox suite running the end-to-end path against a real build rather than against a mock of one.

One release deliberately removed Firestore so the whole system runs through a single HTTP backend. Deleting a dependency is the change that never demonstrates well and always pays.

The plugin makes one demand.

It must confirm a healthy boot. An app that forgets rolls itself back after two cold starts and looks, from the outside, exactly like an update that was broken — which is the most expensive kind of bug, because it points at the wrong thing.

Signing keys are the other cost. A key you lose is a channel you can no longer publish to, and there is no support desk here to reissue one for you.

This is one of the few things here with a backend that has to stay awake, which is the shape of the problem rather than a slip: an update channel needs somewhere for the update to come from.

Everything else I build is arranged so that no server has to be. This one could not be, and that is the honest price of a release path that does not queue behind a store reviewer.

There is no iOS build here. There is no Apple Developer account behind any of this, so Android is where the update path has actually been exercised.

A piece of infrastructure nobody can inspect is a piece of infrastructure nobody should install. The npm page, the 58 pages of documentation and the two runnable example apps are all open to anybody, and that is the whole of the argument.