Over-the-Air Update (OTA)

How an OTA update works

In the classic mobile release cycle, every code change has to pass review in the App Store (usually
one to three days) or Google Play (a few hours). An OTA update skips that cycle: a new JavaScript
bundle or resource is delivered straight to the device at the app’s next launch.

The most common implementations:

Platform limits

The decisive constraint is the app stores’ rules:

Apple (App Store): allows OTA only for minor changes and bug fixes. Not allowed: adding new
features, changing the user experience, bypassing IAP. A breach means removal from the store.

Google Play: less strict, but likewise prohibits bypassing review for substantial changes to
functionality.

Important: OTA is a tool for fixing things fast, not for working around store rules. Using OTA
to add substantial new functionality without review breaks the platform terms.

When to use OTA in e-commerce

OTA is particularly valuable for high-traffic online retailers:

• Critical bugs in checkout — an error in the payment form or the cart has to be fixed in hours,
  not days.
• Urgent changes before a sale — when a fault in price or promo-code display surfaces as the
  campaign starts.
• Copy and localisation — changing wording or campaign terms without a new release.
• A/B tests at the JS level — shipping new variants to specific user segments.

Risks and how to manage them

The main risk of OTA is shipping a broken update: unlike a store release, there is no review here.
The practice that contains it: a staged rollout (1–5% of the audience first), monitoring the crash
rate, and an instant rollback — most OTA platforms support a one-click rollback.