Teams shipping Capacitor live updates keep asking the same question after Apple review emails mention remote code execution: does that block Capgo?
For most Capacitor apps, no. Capgo replaces the web bundle your app already runs. It does not download Swift, frameworks, or bytecode, and it does not turn your product into a mini app store. The rules Apple cites are real, but they target a different class of behavior than signed JavaScript delivered to WKWebView or JavaScriptCore.
This is engineering guidance, not legal advice. Read Apple’s published text and involve counsel for your app.
The three texts reviewers cite
App Review Guideline 2.5.2
Guideline 2.5.2 says apps may not “download, install, or execute code which introduces or changes features or functionality of the app, including other apps.”
Review teams use that line when they see:
dlopen,dlsym, or similar dynamic loading,performSelector:and other runtime hooks toward private APIs, or- remote scripts whose job is to change native behavior after approval.
That is the remote code execution pattern in rejection letters. It is not a ban on every byte downloaded after install.
ADPLA section 3.3.1(B) (interpreted code)
The Apple Developer Program License Agreement section 3.3.1(B) allows interpreted code to be downloaded when it:
- does not change the app’s primary purpose,
- does not bypass signing, sandbox, or other OS security features, and
- does not create a store or storefront for other applications.
Capacitor’s web layer is interpreted code by design. Capgo swaps that layer after your users install the reviewed binary from the App Store.
ADPLA section 3.3.1(C) (additional features)
Section 3.3.1(C) adds another guardrail: without Apple’s prior written approval or a permitted 3.3.9(A) In-App Purchase use, an app may not provide, unlock, or enable additional features or functionality through distribution mechanisms other than the App Store, Custom App Distribution, or TestFlight.
Whether a specific OTA bundle crosses that line is a legal call for your team. Capgo does not make it for you. The compliance checklist names 3.3.1(C) so you can assess each release.
Guideline 4.7 and the November 2025 clarification
Apple’s November 13, 2025 guideline refresh clarified Guideline 4.7 for apps that offer HTML5 and JavaScript mini apps, mini games, chatbots, plug-ins, and similar software not embedded in the binary.
If users browse or launch many distinct software experiences inside your app, you may need 4.7’s catalog, indexing, and age-rating mechanics. Ownership of the bundles does not decide the question. The experience you ship does.
Capgo is a delivery channel for your bundles on your channels. It is not, by itself, a 4.7 marketplace. If your product is a white-label host or mini app platform, treat 4.7 seriously before you rely on OTA.
What Capgo actually ships
| Layer | Capgo behavior |
|---|---|
| Native binary | Unchanged. New plugins, permissions, and entitlements need a store build. |
| Web assets | Signed JavaScript, HTML, CSS, fonts, images, and static files replace the in-app bundle. |
| Execution | Runs inside the WebView or JavaScriptCore engine Apple already approved with your shell. |
| Encryption | Optional end-to-end encryption keeps bundle contents unreadable by Capgo in transit and storage. |
Capgo helps you ship web-layer fixes in minutes, roll back bad bundles on a channel, and keep native releases on the App Store path. Thousands of production apps use that split without turning live updates into a remote native loader.
Practical rules for your team
- Use OTA for bugs, UI, copy, and improvements inside the product Apple reviewed.
- Submit a new binary when native code, SDKs, permissions, or entitlements change.
- Do not use live updates to change pricing models, unlock hidden features, or pivot the app’s purpose.
- Document how updates work in App Review notes when asked.
- Read the full Apple remote code and Capgo section before your next release.
When you want the product view (channels, rollback, signing), start at Capacitor live updates. When you want the policy deep dive, use the compliance doc above or the older walkthrough in Does Apple allow live updates?.
