Store policies
What Apple's interpreted-code clause 3.3.1(B) and Google Play's Device and Network Abuse policy permit and forbid for over-the-air updates, quoted with dates.
Yes, over-the-air (OTA) updates are allowed. Apple and Google both permit an app to update its web or JavaScript layer after review, in clauses written for that purpose. Neither permits delivering native executable code that way, or becoming an app other than the one reviewed.
HotCodePush ships your built JavaScript, markup, styles and assets and nothing else, as What is hot code push? explains. The conditions the stores attach are mostly editorial, and those are yours.
This page quotes both policies verbatim, with the date each quote was retrieved. It says which conditions HotCodePush holds for you and which you hold yourself.
Not legal advice
This page is not legal advice, and no vendor can promise you an approval. Apple and Google review each app and each submission on its own facts.
What Apple says
Two documents matter, and they are not interchangeable. The Apple Developer Program License Agreement is the contract you accepted, and the App Store Review Guidelines are what review applies. The permission lives in the agreement.
The interpreted-code clause 3.3.1(B)
In the current agreement the interpreted-code text is section 3.3.1(B), "Executable Code".
Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code:
(a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application
(b) does not bypass signing, sandbox, or other security features of the OS; and
(c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.
Apple Developer Program License Agreement, §3.3.1(B), document LYL255 dated August 18, 2026, retrieved 2026-09-17.
| The clause | In plain words |
|---|---|
| "an Application may not download or install executable code" | This is the baseline ban: no native libraries, no machine code, nothing the OS would load and run directly. |
| "Interpreted code may be downloaded to an Application" | This is the permission: JavaScript, HTML, CSS and assets may arrive after review. |
| (a) not inconsistent with "the intended and advertised purpose of the Application" | Stay the app you were reviewed as. |
| (b) does not bypass "signing, sandbox, or other security features of the OS" | Do not use the update path to defeat platform protections. |
| (c) no "store or storefront for other Applications" | Do not become an app store. |
The clause does not require the code to run in WebKit or JavaScriptCore. Older agreements carried that condition. Neither word appears in the current one, and the clause does not mention review at all. One condition sits next door rather than inside the clause.
Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
Apple Developer Program License Agreement, §3.3.1(A) "Documented APIs", retrieved 2026-09-17.
That applies to the Application as a whole, downloaded interpreted code included.
App Review Guideline 2.5.2
Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.
App Store Review Guidelines, 2.5.2, guidelines last updated June 8, 2026, retrieved 2026-09-17.
Read alone this looks like a flat ban, which is why it is the sentence people quote at you. Apple maintains both texts at once: 2.5.2 in the review guidelines, and the interpreted-code permission in the agreement every developer signs.
Every over-the-air vendor since 2015 has operated on the agreement in the open. If the gap matters to your risk posture, put both texts in front of your own counsel.
Guideline 2.3.1
Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review. All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.
App Store Review Guidelines, 2.3.1(a), retrieved 2026-09-17.
This is where over-the-air misuse is caught. The next line names the penalty: "Egregious or repeated behavior is grounds for removal from the Apple Developer Program."
A bug fix to your JavaScript is a 3.3.1(B) question, and the answer is yes. An update that switches on something review never saw is a 2.3.1 question, and the answer is no.
What Google says
One document, the Device and Network Abuse policy. Three sentences do the work, and the third is the exception.
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, 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).
Google Play Device and Network Abuse policy, retrieved 2026-09-17.
Google attaches one condition of its own.
Apps or third-party code, like SDKs, with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies.
Google Play Device and Network Abuse policy, retrieved 2026-09-17.
The exception permits the mechanism, not misuse of it: every Play policy that binds your store build binds what you send over the air.
Every condition and who holds it
The native boundary is the one condition HotCodePush holds mechanically. The rest are editorial, and no tool can hold them for you.
| Condition | Source | What HotCodePush does | What you hold |
|---|---|---|---|
| No downloaded or installed executable code | Apple 3.3.1(B), and Google, sentences 1 and 2 | bundle upload packages your framework's built output, and the SDK only points the WebView or the runtime at those files at start. Nothing writes to the binary, loads a native library or replaces the installed app. | Do not hand-place native artifacts into your build directory, since nothing would load them. |
| Interpreted code only, in a VM or interpreter | Google, sentence 3 | Your bundle is web assets rendered by the system WebView, or a JavaScript bundle run by the app's own engine, the exception's own example. | You hold nothing. |
| Does not change the app's primary purpose, and no store for other apps | Apple 3.3.1(B)(a) and (c) | HotCodePush does nothing here, since this is judgement. | Keep every release inside the purpose your listing advertises. |
| Does not bypass signing, sandbox or OS security, and no private APIs | Apple 3.3.1(B)(b) and 3.3.1(A) | Bundles run inside your app's own sandbox, the SDKs call documented APIs only, and the compatibility fingerprint fixes the native plugin set to the one in the binary. With code signing on, the device verifies your signature before it applies anything. | Keep signing on. What your JavaScript calls is yours. |
| No hidden, dormant or undocumented features, and interpreted code must not allow policy violations | Apple 2.3.1(a), and Google | Preview channels let you test without hiding anything in production, and the release log records what shipped when. | Describe new features in Notes for Review when the native build ships, and obey every Play policy in an update as in a release. |
| Native changes go through the store | both, in effect | Every release carries the fingerprint condition of its own bundle, and the CLI warns at upload when a fingerprint matches no registered binary. | Let the warning stop you, since a native change is a store release. |
The App Store screenshot question
App Store Connect accepts screenshot and preview uploads only while a version is in one of five states. Those are Prepare for Submission, Invalid Binary, Rejected, Metadata Rejected and Developer Rejected.
Screenshots cannot be swapped on a live version, and the description changes with a new version as well, while promotional text can change at any time. Guideline 2.3.3 asks that "Screenshots should show the app in use". If a release changes the app enough that the live screenshots misrepresent it, pair it with a store submission.
Bug fixes, copy, styling and iteration inside screens you already show never raise the question.
App Store Connect Help, Upload app previews and screenshots, and Apple, Creating your product page, both retrieved 2026-09-17.
Myths
| Myth | What is true |
|---|---|
| "Every update needs Apple's approval" | No clause in either policy requires a per-update review. What needs review is a change that leaves your reviewed purpose or turns on functionality review never saw. |
| "You must ask the user's permission before updating" | No policy requires or forbids an update prompt. It is a product decision, made in your apply strategy. |
| "A mandatory release breaks Apple's rules about forcing users" | The rule people mean is 3.2.2(x), "Apps must not force users to rate the app, review the app, download other apps, or other store-related actions". That is a store action, not your own app updating its own web layer. |
| "It's a grey area everybody quietly ignores" | It is an explicit written permission in the agreement, and the tooling built on it (CodePush, Appflow, EAS Update, Capawesome) has operated in public for a decade. |
| "The clause is 3.3.2" | It was. It is 3.3.1(B) now, and 3.3.2 is a different subject entirely. |
| "Apple detects the SDK and rejects you" | Neither policy names over-the-air tooling, and no clause requires disclosing one. What is required is disclosing your features at submission. |
Sources
Every quote carries its clause number and the date it was retrieved, and the dates move whenever the texts are checked again.
| Document | Clauses used | Retrieved |
|---|---|---|
Apple Developer Program License Agreement (LYL255, August 18, 2026) | 3.3.1(A), 3.3.1(B) | 2026-09-17 |
| App Store Review Guidelines (last updated June 8, 2026) | 2.3.1(a), 2.3.3, 2.5.2, 3.2.2(x) | 2026-09-17 |
| Google Play Device and Network Abuse | the full policy | 2026-09-17 |
| App Store Connect Help, Upload app previews and screenshots | upload states | 2026-09-17 |
| Apple, Creating your product page | description, promotional text | 2026-09-17 |
Last updated on
Security
The security practices for your HotCodePush account, organization and pipeline, from two-factor and least privilege to tokens and the signing key.
Supported versions
The React Native, Expo, Capacitor and Cordova versions each HotCodePush SDK supports, the minimum iOS and Android versions they set and how a version leaves support.