Do it yourself
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main pageApp Store rejection
Guideline 2.5.2 forbids apps from downloading or running code that changes what the app does after review. A web app loaded in WKWebView is not what Apple is after, so a normal WebViewGold app is safe. Trouble starts when your app runs code it did not ship with: AI-generated mini apps, user plug-ins or hot-patching SDKs.
From $109 one-time per platform, or let our team do it all from $698.
Guideline 2.5.2 asks apps to be self-contained in their bundles. They may not read or write data outside their own container, and they may not download, install or execute code that introduces or changes features or functionality, their own or another app's. There is one narrow exception: educational apps that teach programming may let students download and run code, as long as that code is used for nothing else and the user can fully view and edit the source.
The guideline is backed by the Apple Developer Program License Agreement, whose rule on downloaded interpreted code (section 3.3.1(B) in recent versions) Apple has cited in these cases. In broad terms, downloaded interpreted code is acceptable only if it does not change the app's primary purpose, does not create a store for other code or apps, and does not bypass signing, the sandbox or other security features. Read the current agreement in your developer account for the exact wording.
Guideline 2.5.6 requires apps that browse the web to use WebKit, and WebViewGold does exactly that: your web app runs in WKWebView, Apple's own engine, inside the app's sandbox. Updating the website after approval is how every web-based app works, and it is what WebViewGold apps have done since 2014.
What Apple cares about is purpose, not where the files come from. A habit tracker that gets a new chart on its website is still a habit tracker. A habit tracker that turns into a casino through a remote switch after approval violates 2.5.2 and the hidden-features rule in 2.3.1, whatever technology delivered the change. If a web update changes what the app is, ship it as an App Store update with honest review notes; the guide to web vs native updates shows which changes need a new build.
The note typically says that the app, an extension or a linked framework appears to contain code that can change the app's behavior or functionality after review, or that the app downloads or executes code. Sometimes it names a framework from your project; sometimes it describes a feature the reviewer used, for example that the app lets users create and run apps, or loads executable plug-ins. The reviewer asks you to remove the capability and resubmit.

Great work! Never coded anything but managed to work with this. Easy and fast! Also with great help from the creators!
| What your app does | Verdict | Why |
|---|---|---|
| Loads your web app from your domain in WKWebView; you deploy updates | Fine | Web content in WebKit, same purpose as reviewed |
Bundles the web app in local-www (uselocalhtmlfolder) or keeps an offline copy with zipfiledownloadfromserver | Fine | Your own app, rendered by WebKit; the same reasoning as for the live site |
| An AI returns text, images or structured data that your code renders | Fine under 2.5.2 | Content, not code; the moderation rules of Guideline 1.2 apply |
| An AI or your users generate HTML/JS mini apps that run inside your app | High risk | New software running in your app: at minimum the duties of Guideline 4.7 apply, and app builders were rejected for this in 2026 |
| Plug-ins or extensions users install from a catalog | Only within 4.7 | Index, moderation, In-App Purchase for digital goods, no native APIs exposed |
| Native frameworks or scripts that patch the app at runtime (hot-patching SDKs) | Rejected | The classic 2.5.2 case; Apple warned developers about such frameworks years ago |
| A remote flag that turns on a different app after approval | Rejected, risk of removal | Hidden features (2.3.1) and a changed purpose |
| A coding course where students run the code they write | Possible | Educational exception: the code is fully viewable and editable and used for nothing else |
Reproduce the feature named in the note on the TestFlight build. If the note names a framework, search the Xcode project for it (Podfile, Package Dependencies). Native code that Cursor or Claude Code added to the WebViewGold project is the first suspect; the SDKs the project ships with (OneSignal, Firebase, AdMob, RevenueCat) are widely used and not what 2.5.2 is about.
Delete any SDK that downloads scripts to change native behavior, evaluates downloaded code with access to native APIs, or swaps features through remote config. Keep remote config for texts, content and A/B tests of existing features.
If your product generates or runs code, run it on your server and show the result: output, a rendered image, a test report, an export. You can open live previews in Safari by adding the preview domain to safariwhitelist (URL Handling docs). A browser hand-off alone was reportedly not enough for at least one app builder in 2026, so treat it as risk reduction, not a guarantee.
WebViewGold's URL schemes (push, scanners, contacts, NFC and so on) are triggered by navigations inside the WebView. If user- or AI-generated code runs in your main document, it can trigger them just like your own code. Render generated HTML in a sandboxed iframe on a separate origin, strip custom-scheme links from generated output, and test on the build that generated content cannot open a native feature.
One paragraph: the app shows your web app at your domain in WKWebView; no native code is downloaded; generated content is data rendered by your own code; any code execution happens on your server. Guideline 2.3.1 asks for specific notes on new features anyway, and the review notes template gives you a structure.
Removing an SDK or a native feature needs a new build with a higher build number. If only your web app changed, deploy, verify on the TestFlight build and reply in Resolution Center.
If your app displays HTML that a model or a user produced (formatted answers, reports, charts), keep it out of your main page. An empty sandbox attribute blocks scripts, forms and navigation; a separate origin keeps it away from your session.
<!-- Main app page: never inject generated HTML with innerHTML or dangerouslySetInnerHTML -->
<iframe
src="https://render.yourapp-content.com/view?id=abc123"
sandbox=""
referrerpolicy="no-referrer"
style="width:100%;height:70vh;border:0"></iframe>
<!-- sandbox="" = no scripts, no forms, no top navigation.
Adding allow-scripts means you run generated code: plan for the 4.7 duties and 2.5.2 first.
On the render domain, also remove custom-scheme links (registerpush://, qrcode:// ...) from the output. -->Not every hit is a problem; many are harmless. You are looking for places where text from a model, a user or a remote server becomes executable script.
# Places where a web app executes code it did not ship with
grep -rnE "eval\(|new Function\(|srcdoc|dangerouslySetInnerHTML|insertAdjacentHTML|document\.write\(" \
--include=*.{ts,tsx,js,jsx,html,vue,svelte} \
--exclude-dir={node_modules,dist,build,.next} .Explain the architecture first, then the changes. Reviewers respond well to a precise description.
Hello App Review team, Thank you for your feedback on [App name] [version] ([build]). We would like to explain how the app works and what we changed. How the app works: [App name] displays our web app at [https://yourdomain.com] in WKWebView (WebKit). The app does not download or execute native code, and its purpose is the one described in the submission: [one sentence about what the app does]. What we changed: - [We removed the SDK [name], which could modify app behavior at runtime.] - [Users can no longer create and run mini apps inside the app. Generated content is now returned as text and images that our own code displays; code runs only on our servers.] - [Previews of user projects now open in Safari instead of inside the app.] Where to verify: [screen or steps]. [New build: [number].] If any part of the app still raises a concern under Guideline 2.5.2, we would be grateful if you could point us to the specific screen so we can address it directly. Best regards, [Name], [email], [phone]
eval or new Function on model output.Yes, as long as the app keeps the purpose and features it was reviewed with. Bug fixes, new content and new screens within the same purpose are normal for web-based apps. A change of purpose, or features that need new permissions or purchases, belongs in an App Store update with review notes.
No. A chatbot sends text and receives text or images that your code displays; that is content. Chatbots are mentioned in Guideline 4.7, and Guideline 1.2 asks for filtering and reporting of generated content.
It downloads an offline copy of your own web app that WebKit renders when the device has no connection. It is the same app with the same purpose as the live site, so the same reasoning applies as for the URL. Do not use it to deliver functionality the reviewed app does not have.
Apps that help people build apps exist, but running the generated apps inside your own app is where reviews failed in 2026. Generate and run on your server, deliver results as files, exports or web previews, and expect a careful review. Check the current wording of 2.5.2 and 4.7 before you plan the feature.
Yes, if it downloads or loads executable code, changes app behavior based on remote instructions or calls private APIs. Keep native edits to Config.swift and the documented WebViewGold options, and let the AI agent work on the web app instead.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered byWinter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.