A production bug on a website is a bad hour: you fix it, you deploy, and the next page the user loads is the right one. On a mobile app, the same bug can last for days. You have to build a new version, submit it to Apple and Google, wait for their review, then wait for every user to install the update. Some only do so weeks later. Meanwhile, the bug is still there, in their pocket.
What the rules allow
The general rule is strict. At Apple, guideline 2.5.2 forbids an app from downloading or executing code that introduces or changes its features. At Google, an app distributed on Google Play may not update itself by any means other than Google Play’s update mechanism.
But both texts leave an opening for interpreted code, the kind an engine embedded in the app reads and runs, which is how some cross-platform apps work. Apple’s developer agreement allows it, provided that code does not change the app’s primary purpose as advertised, does not bypass the system’s security features and does not create a store for other apps. Google exempts from its restriction code that runs in a virtual machine or an interpreter with only indirect access to the system.
In practice, for an app built that way, fixing a bug, adjusting a piece of text or repairing a screen can be done remotely. Quietly adding a feature that review has never seen cannot: that is precisely what the rules target, and the risk is the app’s removal.
What always goes through the stores
- Anything that touches native code: a new module, a new permission (camera, location, notifications), an update of the underlying framework.
- Anything that changes what the app is: a significant new feature deserves a real release, described to the review teams.
- The app’s identity: its name, its icon, its screenshots and its store listing.
The safeguards to put in place
Pushing code to thousands of phones without anyone in between is a power that calls for discipline. A poorly controlled remote update can break the app for everyone in a minute, which no isolated bug ever does. Four precautions make the difference:
- Sign every update, so the app rejects anything that does not come from you.
- Respect compatibility: an update must only reach installed versions able to run it.
- Test on a copy of production before publishing, with real data and real user journeys.
- Be able to roll back in one move, if something still goes wrong.
Remote updates are a safety net, not a back door.
The best fix needs no update at all
Another way to gain responsiveness is to leave decisions that may change to the server: what is shown, to whom, in what order. A rule that lives on the server is fixed for everyone instantly, without publishing anything to phones. That is the approach we took on Nakama, our social network for anime and manga: the anti-spoiler veil is decided by the server, and for the rest, a fix reaches phones the next time the app opens, signed by us, after being tested on a copy of production.
If your app takes days to receive a fix, or if every update is a source of anxiety, this can be worked on without rebuilding everything. It is part of what we mean by a product, never a demo, and of our work in product engineering. Tell us about your app: we will look at what can be fixed remotely, and how to do it safely.