A bug fix that has to wait for store review to reach users is a bug fix that keeps costing the business every day of that wait, which is exactly the pain over-the-air updates exist to solve: pushing a new JavaScript bundle directly to installed apps, bypassing the store review cycle entirely for the specific class of change that is genuinely just JavaScript and asset changes. This capability is real and valuable, and it is also the single most misunderstood tool covered in this course, because the temptation to treat it as a general escape hatch from app store review is exactly the temptation both major platforms' policies were written to prevent.
The previous lesson's entire release pipeline — build, sign, submit, wait for review — exists because native code changes genuinely need that scrutiny: a new permission, a new native dependency, a change to what the app fundamentally does. An OTA update's entire value proposition is that it operates underneath that native layer, shipping only the interpreted JavaScript and assets that the already-reviewed native binary was built to run. The moment an update needs anything the native binary was not already built to support, it has stopped being an OTA update and has become a native release wearing an OTA update's name — and shipping it as one is a policy violation, not a clever shortcut.
Analogy🏏Cricket
🏏 Think of it like cricket: A team is allowed to make tactical substitutions and field changes throughout an innings without any external approval, adjusting the bowling order, moving fielders, sending in a different batter at the fall of a wicket — the match officials do not need to sign off on any of that because it happens entirely within the rules and the squad that was already approved before the toss. What a team cannot do mid-match is bring in a player who was never part of the approved squad, no matter how tactically useful that substitution might be — that requires an entirely separate approval process that happens before the match, not an in-match workaround. Cricket's substitute-player rules draw exactly this line, permitting genuine tactical flexibility within an approved squad while requiring separate, prior approval for anything outside it. Just as tactical changes within an approved squad need no new sign-off, JavaScript and asset changes within an already-reviewed native binary need no new store review. Just as bringing in an unapproved player requires going back through a separate approval process, adding a new native capability requires going back through actual store review. The insight is that the boundary of what was already approved is the boundary of what can change freely — and mistaking a genuinely new capability for a permitted in-match adjustment is the exact mistake that gets a team, or an app, penalized.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.