Rejection decoder › Guideline 2.5.2

Guideline 2.5.2 rejection: apps must be self-contained

Guideline 2.5.2 says an app has to be a self-contained bundle. It may not download or run code that adds or changes its features after review. For a wrapped web app, the question Apple is really asking is: is the thing we reviewed the thing users will get?

What Apple's message says

Paraphrased: the app downloads, installs or executes code that introduces or changes its features or functionality, so what Apple reviewed can change without a new review. Apple sometimes adds that the app appears to load its main content from a remote server, or that it lets users create and run other apps or code.

The guideline sits next to the developer agreement, which permits some downloaded interpreted code (such as JavaScript) as long as it does not change the app's primary purpose, create a store for other code, or get around signing and the sandbox. That exception is narrower than many live-update tutorials suggest.

Why AI-built apps hit it

Most AI builders produce a website first. The shortest path to an iPhone app is to point a native shell at that website, which is exactly the pattern 2.5.2 is written against:

• capacitor.config.ts has server.url set to the live site (for example the builder's published URL), so the app bundle contains almost nothing and every feature comes from the server.
• A live-update service is set up to replace the whole web bundle, including new screens and features, without a new build.
• The app itself is an AI tool that generates small apps or scripts and runs them on the device.
• Feature flags turn on large unreviewed sections after approval, such as a hidden marketplace or payment area.

The same setup often draws a 4.2 finding as well, because a remote site in a shell also tends to feel like a browser tab.

How to fix it, step by step

What to reply in the Resolution Center

Fill in the brackets and delete anything you did not do. Say plainly where the app's code now comes from.

Hello,

Thank you. In build [version], the app's interface and features are bundled in the app binary and no longer load from a remote website. The app contacts our server only for [account data / the user's content]. [If you kept a live-update service: "Over-the-air updates are limited to bug fixes and content, and new features will be submitted for review."]

Best regards,
[Your name]

Related guidelines

• Guideline 4.2: Minimum functionality because a remote site in a native shell usually draws both findings.
• Guideline 2.1: App completeness and Information Needed if features were hidden from the reviewer behind flags or a login.
• Guideline 5.1.2 / ITMS-91053: Privacy manifest because bundling locally is a good moment to update Capacitor and add the manifest.

Questions

Is loading my website in a Capacitor app a 2.5.2 problem?

It can be. If the app's features all come from a remote URL, what Apple reviewed can change at any time, which is what 2.5.2 is about. Bundling the web build inside the app and calling your server only for data is the usual fix.

Are live updates (over-the-air JavaScript updates) allowed?

Apple's developer agreement permits some downloaded interpreted code if it does not change the app's primary purpose or add features beyond what was reviewed. Using live updates for bug fixes and content is the common reading; shipping new features that way is a risk.

Can my app let users generate and run code?

Some cases are allowed with limits, such as education apps where the code is visible and editable. A general feature that builds and runs new apps inside yours is a harder case. Read the current 2.5.2 and 4.7 text; Apple decides.