OtaKitApple guideline 2.5.2 explained for OTA updates
The exact wording of App Store Review Guideline 2.5.2, the WebKit/JavaScriptCore exception it grants, and what it means in practice for Capacitor apps shipping over-the-air updates.
Almost every “can I do OTA updates on iOS?” question comes down to one App Store Review Guideline: 2.5.2. It's short, it's often misread, and once you understand what it actually restricts, the compliance picture for Capacitor apps gets very clear. This post walks through the guideline and what it means in practice.
Short version: 2.5.2 bans downloading code that changes your app into something App Review didn't see — with an explicit exception for JavaScript running in Apple's own web view. Capacitor's web layer lives in that exception.
What the guideline says
Guideline 2.5.2 requires that apps be self-contained in their bundles and not read or write data outside their designated container, and that they not download, install, or execute code which introduces or changes features or functionality — creating an experience that differs from what App Review approved. Historically this connects to rule 3.3.1 in the developer agreement about interpreted code.
The critical clause is the carve-out: code executed by Apple's built-in WebKit framework or JavaScriptCore is permitted, provided it doesn't provide native store, payment, or other capabilities that would circumvent review.
Why Capacitor apps fit the exception
A Capacitor app's entire web layer — your HTML, CSS, and JavaScript — runs inside the WebKit web view that 2.5.2 explicitly allows. Updating that web layer over the air is precisely the sanctioned case. This is why every major Capacitor OTA tool (OtaKit, Capgo, Capawesome) and Ionic's own Appflow all operate the same way. It's not a loophole; it's the documented behavior.
What 2.5.2 still forbids
The guideline draws a real line, and OTA has to respect it:
- No native code over the air. Downloading and executing native binaries or plugins to change functionality is exactly what 2.5.2 targets.
- No materially different app. You can improve and fix what was reviewed; you can't use OTA to turn the app into something else.
- No circumventing review-gated capabilities. Payments, in particular, must stay within Apple's rules — you can't OTA your way around In-App Purchase.
How to stay clearly on the right side
The practical test is simple: if a change would require you to modify native code — and therefore bump runtimeVersion and submit a store build — it's not an OTA update. Keep OTA to the web layer, and you're operating squarely inside the WebKit exception. OtaKit reinforces this by checking your bundle's dependencies at upload and warning on native mismatches.
One rule covers most of it: web-layer changes ship over the air; anything native ships through review. That's the shape of 2.5.2 in day-to-day terms.
Where to go next
For the broader store picture including Google Play, see the complete App Store-compliant OTA guide and the primary-source breakdown in are OTA updates allowed? App Store and Google Play rules explained.