What an over the air update can change in an app without store review

A React Native or Expo app has two parts. The native shell is compiled code that the store installs: camera access, push handling, the navigation container. On top sits a JavaScript bundle plus images and fonts that the shell loads when it starts.

An over the air update swaps only the top layer. The shell stays exactly as the store approved it. On the next launch the app fetches the new bundle, checks it matches the installed shell, and runs it.

Think of the shell as a phone and the bundle as the contents of a folder on it. Ask your developer which runtime version each installed shell reports. Without that number, nobody can say which phones will accept a given update, and field staff on old builds get left behind. Keep the list in the project notes.

Most day to day fixes live in the bundle. A wrong rounding rule on a quotation, a mislabelled button, a form field that should be required, a crashed list when a customer name is empty. All of these ship by update.

The same goes for layout work and new screens built from components the shell already has. A new inspection form for a field team is a good example, as long as it only uses the camera and storage access the app was already granted.

Anything the shell must know at install time cannot be patched in. Adding the location permission, the Bluetooth permission or a microphone prompt changes the app’s manifest, so a new binary goes through review.

Adding a library with native code, such as a barcode scanner or a printer SDK, also needs a build. So does upgrading the Expo SDK or React Native version, changing the app icon or splash image, and editing the bundle identifier.

Plan these changes in batches. A store build every few months, packed with every native need, is easier to manage than one build per request. An update that expects a native module the installed shell lacks will crash on launch. Tie each update to a runtime version so old shells only receive bundles built for them.

Take a delivery driver whose proof of delivery screen rejects a valid pincode. A store release means building, submitting, waiting for review and then waiting again for each phone to update. That can stretch over days.

With an update, you fix the validation, publish to a test channel, check it on two real handsets and promote it to production. Phones fetch it the next time the app opens. Drivers do not visit a store at all.

Keep the previous bundle published. If the new one misbehaves, repoint the channel to the old one and the fix reverses within the same hour.

Store policies expect updates not to change the app’s main purpose. Keep them for fixes and improvements, and read the current guidelines from Apple and Google before relying on this for large changes.

Use channels for staging and production, sign your updates, and log which bundle version each user is running. Support calls are easier when you can see that a complaint came from an old bundle.

Before the next release, list the permissions the roadmap will need in the next six months. Ask for them in one store build, then use updates for everything else.