WebView App Rejected Under Guideline 2.5.2: Web Content, Live Updates and Downloaded Code

What Guideline 2.5.2 and Apple's license agreement say

A WebView app rejected under Guideline 2.5.2 stands accused of something specific: running code App Review never saw that changes what the app does. The guideline reads (App Store Review Guidelines):

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. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

Section 3.3.1(B) of the Apple Developer Program License Agreement (updated August 18, 2026) draws the technical boundary. An app "may not download or install executable code". Interpreted code may be downloaded, but only so long as it:

(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.

JavaScript on a web page is interpreted code, and Guideline 2.5.6 requires apps that browse the web to use WebKit – which is exactly what WKWebView is. So a WebView app is not a violation by default. The real question is never "does my app run JavaScript?" but "does the code it downloads change what the app is or does?"

Web content or downloaded functionality? Where the line runs

Apple's neighboring rule, 2.5.1 (public APIs, deprecated technologies such as UIWebView), is a different problem with its own fixes – see our 2.5.1 Software Requirements guide.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

When a WebView app gets rejected under Guideline 2.5.2

These designs tend to draw 2.5.2 questions:

• The loader shell. The binary holds little more than a WebView, and a remote configuration decides which product it shows – recipes today, a casino tomorrow. That changes the primary purpose by design and touches Guideline 5.6 as well.
• A bridge that grows after review. Your web code starts calling native functions it never used during review, such as contacts access or background location. The capability was compiled in, but the feature arrived remotely – a dormant feature under 2.3.1 that can also read as remote code changing functionality.
• Downloadable modules. ZIP packages or script bundles that unlock new sections, sometimes as paid add-ons, which brings 3.1.1 payment rules into play.
• Other people's code. Plug-in directories, template galleries or "run your project" previews. Each item is software App Review never saw, and a catalog of them can look like a storefront for other apps.
• Live updates as the release channel. Every feature goes out over the air while the App Store build stays months behind.

Compare that with an ordinary WebView app: there, the website is the product, and its purpose was clear when App Review approved it.

Live updates in Capacitor and React Native apps: the rules of the road

Hybrid frameworks ship web or JavaScript bundles inside the app and can replace them over the air. The vendors describe the limits themselves:

• Capgo (Capacitor) updates only "the HTML, CSS, JavaScript, and assets already running in the app’s WebView" and advises: "Use a native store release for every native change and for material changes that could affect the app’s reviewed purpose or functionality." (Capgo FAQ)
• Expo EAS Update (React Native) says updates must follow the store guidelines and that "this usually means changes to your app's behavior need to be reviewed" (Expo documentation).
• CodePush continues as a self-hosted server after Microsoft retired Visual Studio App Center on March 31, 2025 (Microsoft Learn).

The same principle applies to any over-the-air mechanism, including those in Cordova projects. A workable policy: fixes, copy, translations, styling and small improvements to reviewed features go over the air. New features, new permissions and anything touching payments or sign-in go through the App Store – like all native changes, which live updates can't deliver anyway. Saying in the review notes that live updates are limited to fixes is transparency, not a confession.

One Capacitor detail: its option to load a remote URL is documented as "intended for use with live-reload servers" and "not intended for use in production" (Capacitor docs). If you want your live website as the app, a wrapper built for that job is cleaner – our Capacitor alternatives article compares the options.

HTML5 mini apps and mini games: Guideline 4.7

Some WebView apps offer games or tools made by others. For that, Apple has a dedicated rule. Guideline 4.7 begins:

Apps may offer certain software that is not embedded in the binary, specifically HTML5 and JavaScript mini apps and mini games, streaming games, chatbots, and plug-ins. Additionally, retro game console and PC emulator apps can offer to download games. You are responsible for all such software offered in your app, including ensuring that such software complies with these Guidelines and all applicable laws.

The sub-rules make that responsibility concrete: the software follows the privacy rules, comes with filtering, reporting and blocking, and uses In-App Purchase for digital goods (4.7.1). Your app may not expose native platform APIs to it without Apple's prior permission (4.7.2) or share data and privacy permissions with an individual piece of software without explicit consent each time (4.7.3). You also need an index of all offered software with universal links (4.7.4) and an age restriction mechanism for software above your app's age rating (4.7.5).

4.7.2 matters for WebView apps with a JavaScript bridge: your own pages calling your own native features is normal, but third-party games calling the same bridge need Apple's permission. If you host other people's software, plan for 4.7 from the start.

The March 2026 vibe-coding case – and why your WebView app is different

In March 2026, Apple stopped updates of AI app builders such as Replit and Vibecode unless they changed their apps, as reported by The Information and 9to5Mac (March 18, 2026). Apple pointed to Guideline 2.5.2 and to section 3.3.1(B) of the license agreement, and said it has no App Store rules specifically against vibe coding apps. According to the reports, one way out was to show previews of generated apps in a web browser instead of inside the builder app.

The logic is easy to follow. In those tool apps, every prompt produces a new app that then runs inside the host app, so the host's functionality changes with each generation. A WebView app of your own website does the opposite: it presents one service with one purpose – the one App Review approved.

Apps built with Replit, Lovable and similar tools are therefore not what this case was about. Their review risks lie elsewhere, mostly in changes after approval – see how to turn a Replit app into an iOS app and our overview of AI-built apps and Guideline 5.6.

Remote URL or local HTML bundle? Choosing a WebViewGold setup

WebViewGold, the website-to-app product developed by our team, supports both models in its Xcode project, and the choice shapes your update process:

In every setup the native side is fixed at build time. Push notifications, Face ID, the QR scanner or In-App Purchases are modules you enable in the project, and your web code can only use what the reviewed build contains – so new native capabilities always come with a new build. WebViewGold can also refresh an offline copy of your site from a ZIP file on your server; treat it like your website, as a copy of the reviewed experience. If such a package is needed on first launch, Guideline 4.2.3(ii) asks you to disclose its size and prompt users before downloading. Unsure which model fits? The App Specialists at appsubmitter.io can weigh it with you before you build.

Fixing a 2.5.2 rejection and explaining your architecture

1. Map every remote input. List the URLs, bundles, configs and scripts the app loads after installation. Safari's Web Inspector shows a WKWebView's traffic once you set isInspectable (iOS 16.4 and later) in a debug build.
2. Classify each input with the table above: content, interpreted code within the reviewed purpose, or functionality that belongs in the binary.
3. Limit live-update channels to fixes and write that policy down.
4. Move new features into a build or gate them by app version, and describe them in the Notes for Review.
5. Stop hosting foreign code or implement Guideline 4.7 completely.
6. Explain the architecture in your reply: what is loaded remotely, what sits in the binary and why remote content can't change the app's purpose.

If App Review mistook a plain website for downloaded functionality, a calm explanation – and, if needed, an appeal to the App Review Board – is the right path. appsubmitter.io handles exactly this conversation for WebView and hybrid apps: we review your setup, write the notes and talk to App Review from your own developer account; code changes are quoted separately upfront. Book the iOS service or describe your setup in a free consultation call.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 2.5.2.

We would like to explain how the app works and what we changed:

- The app displays our web service [domain] in WKWebView. This content provides [bookings / articles / account management] for the purpose described in our App Store listing.
- All native functionality ([push notifications, Face ID, QR scanner]) is included in the binary. The web content cannot add native capabilities.
- [We removed the downloadable module system that unlocked [feature]. [Feature] is now part of build [build number] and described in the Notes for Review.]
- [Our live-update channel is limited to bug fixes and text changes for features included in the reviewed build.]

The app does not download or execute code that introduces or changes its features or functionality. If a specific screen or behavior raised the concern, we would be grateful for a pointer so we can address it directly.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Every remote input the app loads after installation – URLs, bundles, configs, scripts – is listed and classified.
• The app's primary purpose stays the same for every remote configuration; there is no loader shell that can become a different product.
• New features arrive with a new build or are gated by app version and described in the Notes for Review.
• Live-update channels deliver only fixes, copy and styling for features App Review has seen.
• No executable code, frameworks or plug-ins are downloaded after installation.
• Third-party mini apps or games, if offered, meet Guideline 4.7, including no native API access without Apple's permission.
• In WebViewGold or any other wrapper, native modules are switched on only if the reviewed version uses them.
• Offline packages needed on first launch show their size and ask the user before downloading.
• Your reply explains what is loaded remotely and what is part of the binary.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 2.5.2 Software Requirements
• Apple – App Store Review Guidelines, 4.7 Mini apps, mini games and plug-ins
• Apple – Apple Developer Program License Agreement (section 3.3.1(B) Executable Code)
• 9to5Mac – Apple pushing back on vibe coding iPhone apps (March 18, 2026)
• Capgo – FAQ: App Store and Play Store policies
• Expo – EAS Update introduction
• Capacitor – Configuration (server.url)
• Microsoft Learn – Visual Studio App Center retirement

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.