Policy / App-store compliance

OTA Update Compliance Notice

This notice describes the compliance boundary that governs every Over-The-Air (OTA) update delivered through PatchForge. It is based on PatchForge's OTA Update Compliance Policy. Please read it in full before publishing any release.

1. Overview

PatchForge delivers Over-The-Air (OTA) updates for React Native apps, allowing you to ship changes to your app without going through a full App Store or Google Play submission for every update.

This capability exists only because of a strict, non-negotiable boundary: PatchForge OTA updates are limited to JavaScript and asset changes. Native code may never be delivered or executed over the air. This notice explains that boundary, why it exists, how it aligns with Apple and Google policies, and how PatchForge enforces it on the platform side. Every customer who deploys releases through PatchForge must respect this boundary.

2. What may be shipped OTA

The following content may be delivered over the air, because it forms the JavaScript and asset layer of a React Native app and does not alter the native code path of the installed binary:

JavaScript bundles — the JavaScript produced by the Metro bundler that runs inside your app's React Native JavaScript engine.
Static assets referenced by the bundle — images, fonts, and JSON or other configuration/data files packaged alongside the JavaScript bundle.
Patch files — binary diffs between consecutive JavaScript bundles, used to download only what changed instead of the whole bundle. A patch reconstructs a permissible JavaScript-and-assets bundle; it never introduces native code.

Why these are permitted. React Native's architecture separates the JavaScript layer from the native binary. The JavaScript bundle and its assets are interpreted at runtime by the JavaScript engine that is already compiled into the app submitted to the store. Because updating this layer does not change the native code path, Apple and Google permit it without a new store review (see sections 4 and 5).

3. What may NOT be shipped OTA

Native code may never be delivered or executed over the air. The following must never be included in a PatchForge release:

Native binary code — compiled libraries and executables such as .so, .dylib, .a, .framework, .xcframework, .aar, .node, and any Mach-O or ELF binary.
New native modules or plugins that were not already compiled into the app binary you submitted to the App Store or Google Play.
Executable code that runs outside the React Native JavaScript engine.
Any change that alters the app's declared purpose, privacy practices, or core functionality in a way that would require a new App Store or Google Play review.

This boundary is not optional. Misuse — for example, attempting to deliver or load native code, or materially changing what the app does — risks rejection or removal of your app from the App Store or Google Play, and is a breach of those platforms' terms of service. This liability rests with the deploying organization.

4. Apple App Store alignment

Apple App Store Review Guideline 2.5.2 permits an app to download and run interpreted code (such as JavaScript) provided the downloaded code does not change the app's primary purpose, provide features inconsistent with the app's intended and advertised purpose, or otherwise circumvent App Store review.

PatchForge OTA updates qualify under this exception only when they deliver JavaScript and assets — the permitted content described in section 2. Delivering native code does not qualify and is prohibited.

You are responsible for ensuring that your specific use of OTA updates complies with Apple's guidelines as they exist at the time you publish a release. Apple's guidelines may change; consult the current App Store Review Guidelines before deploying.

5. Google Play alignment

Google Play Developer Policy imposes an analogous restriction: an app distributed through Google Play may not download executable code (for example, dex, JAR, or .so files) from a source other than Google Play. Interpreted updates to the JavaScript layer are permitted on the same basis as Apple's exception; delivering native or otherwise executable code is not.

As with Apple, PatchForge OTA updates qualify only when they deliver JavaScript and assets, never native code.

You are responsible for ensuring that your specific use of OTA updates complies with Google's policies as they exist at the time you publish a release. Google's policies may change; consult the current Google Play Developer Program Policies before deploying.

6. How PatchForge structurally enforces the boundary

PatchForge enforces the policy on the platform side through signature verification, store-version compatibility, and bundle integrity checks. The SDK installs only files within a signed bundle and never loads native libraries delivered over the air. Concretely:

Signed-bundle-only install. The SDK activates a bundle only after its signature and integrity have been verified. There is no code path in the SDK that loads or executes a native library received over the air.
Install-time guard. The SDK's installer rejects any bundle whose path matches a native-binary signature (for example, .so, .dylib, .a, .framework, .xcframework, .aar, .node) before installation, refusing to activate it.

Enforcement point: packages/sdk-react-native/src/installer/Installer.ts.
Patch-time guard. The SDK's patch applicator inspects every entry in a patch's changes.json manifest and rejects any patch that references a path matching a native-binary signature (or an unsafe path) before applying the patch. A rejected patch falls back to a full, permissible bundle download.

Enforcement point: packages/sdk-react-native/src/patching/PatchApplicator.ts.

These guards are structural — always enforced and not configurable — and serve as defense-in-depth. PatchForge cannot inspect bundle contents for policy compliance: these checks block native binaries, but they do not and cannot judge whether your content is otherwise permissible under Apple's or Google's policies. The platform's structural defence is not a substitute for your own compliance. A compliance warning is also shown in the Release Wizard at deploy time.

7. Customer responsibility

PatchForge provides the structural enforcement described in section 6, but the deploying organization is solely responsible for ensuring that releases contain only permissible changes. Specifically, you are responsible for:

Ensuring that the content of every bundle you deploy complies with Apple and Google policies at the time of delivery.
Reviewing the App Store Review Guidelines and the Google Play Developer Policy for any updates that may affect your releases.
Seeking your own legal advice if it is unclear whether a particular use case is permitted.

PatchForge does not warrant or guarantee that any given release complies with Apple's or Google's policies. That responsibility, and any liability arising from non-compliant releases, rests with the deploying organization.

8. Reporting a concern

If you believe a PatchForge release violates this policy, please contact the platform operator so the concern can be reviewed.