Skip to content
WebViewGold Vibe Coding to App Store
English
Get WebViewGold

App Store rejection

Guideline 2.5.2 (self-contained apps): why your web app is fine and where AI-generated code crosses the line

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.

  • Approval guarantee – or money back within 14 days
  • No coding needed
  • One-time payment, free updates
  • 24/7 human support
  • Made in Germany since 2014 · ISO 27001

What 2.5.2 says, and the agreement behind it

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.

Why a web app in WKWebView passes

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.

What the rejection message usually says

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!

Lucas Dubois · CodeCanyon

Where the line runs

What your app doesVerdictWhy
Loads your web app from your domain in WKWebView; you deploy updatesFineWeb content in WebKit, same purpose as reviewed
Bundles the web app in local-www (uselocalhtmlfolder) or keeps an offline copy with zipfiledownloadfromserverFineYour own app, rendered by WebKit; the same reasoning as for the live site
An AI returns text, images or structured data that your code rendersFine under 2.5.2Content, not code; the moderation rules of Guideline 1.2 apply
An AI or your users generate HTML/JS mini apps that run inside your appHigh riskNew 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 catalogOnly within 4.7Index, moderation, In-App Purchase for digital goods, no native APIs exposed
Native frameworks or scripts that patch the app at runtime (hot-patching SDKs)RejectedThe classic 2.5.2 case; Apple warned developers about such frameworks years ago
A remote flag that turns on a different app after approvalRejected, risk of removalHidden features (2.3.1) and a changed purpose
A coding course where students run the code they writePossibleEducational exception: the code is fully viewable and editable and used for nothing else

Fix steps when 2.5.2 hits your app

  1. Find out what the reviewer saw

    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.

  2. Remove runtime patching and remote native code

    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.

  3. Move code execution off the device

    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.

  4. Keep the native bridge for your own code

    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.

  5. Describe the architecture in the review notes

    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.

  6. Upload a new build if the binary changed

    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.

Show generated HTML without running it in your app

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.

xml
<!-- 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. -->

Audit your web app for code execution

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.

bash
# 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} .

Resolution Center reply template

Explain the architecture first, then the changes. Reviewers respond well to a precise description.

Reply in Resolution Center (keep only the lines that apply)
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]

Checklist

  • No SDK or native code that downloads scripts or patches the app at runtime.
  • Remote config changes texts, content and existing features only, never the purpose of the app.
  • AI output is rendered as data by your own code; no eval or new Function on model output.
  • Generated or user-made HTML never runs in the main document and cannot trigger WebViewGold URL schemes.
  • Plug-ins or mini apps, if you offer any, meet the 4.7 duties.
  • The review notes describe the architecture and every new feature specifically.

Frequently asked questions

Can I update my web app after approval without a new review?

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.

Is an AI chatbot in my app remote code?

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.

Does the WebViewGold offline zip download count as downloading code?

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.

I built an app builder. Can it be on the App Store?

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.

Can native code that Cursor or Claude Code added cause a 2.5.2 rejection?

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.

Three ways to get your app into the stores

Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.

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 page

Cloud Builder

$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

Full Service

$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 by WeSetupYourWebViewApp

Winter Sale prices valid until December 31, 2026.

Ready to ship your app?

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.