Are OTA updates allowed? App Store and Google Play rules, explained

Short answer: yes, over-the-air updates are allowed — for the web layer of your app, under conditions both Apple and Google spell out explicitly. Teams don't get rejected for “using OTA.” They get rejected for using it to change what the reviewed app fundamentally is, or to download code the platforms classify as executable.

This post quotes the actual policy text from the primary sources, then translates it into a practical checklist. It's not legal advice, but every claim below links to the document it comes from.

What Apple says

Two documents matter: the App Review Guidelines and the Apple Developer Program License Agreement (DPLA).

Guideline 2.5.2 sets the baseline: apps “should be self-contained in their bundles… nor may they download, install, or execute code which introduces or changes features or functionality of the app.”

Read alone, that sounds like a blanket ban — but the DPLA carves out interpreted code explicitly. The clause historically known as §3.3.2 (moved to §3.3.1(B), Executable Code in the 2025 reorganization of the agreement) permits downloaded interpreted code — JavaScript included — as long as it is run by Apple's built-in WebKit framework or JavaScriptCore, and provided it:

• does not change the primary purpose of the app,
• does not create a store or storefront for other code or apps, and
• does not bypass the operating system's signing, sandbox, or other security features.

A Capacitor app runs its entire web layer inside Apple's own WKWebView — WebKit, exactly the engine the clause names. Updating that web layer over the air sits squarely inside the carve-out, which is why live-update tooling has operated in the open for a decade, from Microsoft's CodePush and Ionic Appflow to today's Capacitor ecosystem.

The guidelines Apple actually enforces against OTA misuse are elsewhere: guideline 2.3.1 bans “hidden, dormant, or undocumented features” and requires that “your app's functionality should be clear to end users and App Review.” Using OTA to flip on functionality reviewers never saw is what gets developer accounts in trouble — not shipping a bug fix to your JavaScript.

What Google says

Google Play's Device and Network Abuse policy is the primary source, and it's unusually direct. Three sentences do all the work:

• “An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism.”
• “An app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play.”
• “This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).”

That third sentence is the OTA exception, verbatim: JavaScript running in a WebView — which is precisely what a Capacitor app is — is explicitly excluded from the ban. Google adds one condition: interpreted code loaded at runtime “must not allow potential violations of Google Play policies.” The exception permits the mechanism, not misuse of it.

The practical line

Putting both platforms together, the compliant zone is wide and clearly marked.

Safely in bounds:

• Bug fixes in your JavaScript, CSS, and HTML.
• UI polish, copy changes, new screens built on existing native capabilities.
• Feature iteration that stays inside the app's reviewed purpose.
• Staged rollouts, instant rollbacks, and channel-based testing of the web layer.

Rejection territory:

• Downloading native or otherwise executable binaries (dex, JAR, .so, dylibs) outside the stores.
• Using OTA to activate features that were hidden from review (Apple 2.3.1).
• Materially changing the app's primary purpose after review — the classic example is an app reviewed as one thing that turns into a casino a week later.
• Behaving differently for reviewers than for real users.

How OtaKit keeps you on the right side

OtaKit is deliberately scoped to the compliant slice: it delivers web bundles only, and the toolchain reinforces the boundary. The CLI inspects your dependencies at upload time and warns when a bundle depends on native code the installed app doesn't have — the most common accidental way teams drift out of bounds. Signed manifests and SHA-256 verification mean the only code that can reach devices is code you published. And when a native change is genuinely needed, runtimeVersion lanes make “this goes through the store” an explicit, first-class part of the release model rather than an afterthought.

A five-point checklist for your team

1. Keep OTA payloads strictly to built web output — no native artifacts, ever.
2. Describe new features honestly in store metadata and review notes when you submit native builds.
3. Don't gate unreviewed functionality behind remote flags aimed at review.
4. Bump runtimeVersion with every store build that changes native capabilities.
5. Re-read both policy pages once or twice a year — they do evolve.

Want to see the compliant workflow in practice? Start with the setup guide, or read how OTA updates actually work under the hood.