AppReviewFix
Guideline library
Apple App Store — App Quality

2.5.2 — Self-contained apps

Official source: App Store Review GuidelinesTopic overview: The review process, app quality and enforcement
What this guideline means

The app submitted for review has to be the complete, self-contained product — it can't fetch and run executable code, scripts, or plugins after install that change its core functionality beyond what was reviewed.

Why apps actually get flagged

Common with apps that use a remote-config or scripting SDK, often for A/B testing or hotfixes, in a way that changes app behavior beyond simple content or copy updates.

A real example

"Your app downloads code in a way that introduces or changes features or functionality without being reviewed, per guideline 2.5.2."

The short version, in more detail

Guideline 2.5.2 says an app must be self-contained. It cannot download or run code after installation that changes its main purpose beyond what App Review saw. The reviewed binary is meant to be the complete product, so remote scripting and plug-in systems that alter behaviour fall under this rule.

Why this rule exists

App Review can only approve what it can inspect. If an app can download new executable logic later, the version that was reviewed may not be the version users actually run, and the review loses its meaning. The self-contained requirement closes that gap, so that what Apple tests is what ships. It is also a security measure, because downloaded code is a classic route for introducing behaviour that no one checked.

What this guideline covers

  • Downloading and executing code at runtime.
  • Scripting engines and plug-in frameworks.
  • Remote configuration that changes behaviour.
  • The line between content updates and executable changes.

What usually triggers this rejection

  • A scripting or remote-config SDK used to change features after review.
  • Downloading executable modules.
  • Delivering app logic through a web service in a way that replaces native functionality.
  • Hot-patching tools that alter behaviour.
  • Apps that load code to circumvent review.

How reviewers evaluate it

  • Reviewers inspect SDKs and the way features are delivered.
  • They consider whether behaviour can change after approval.
  • They treat circumvention as serious.
  • Interpreted code is allowed only in narrow cases.

Common misunderstandings

  • Updating copy or assets remotely is normal. Executable changes are the issue.
  • A third-party tool does not change responsibility.
  • Apple allows some interpreted code in specific circumstances.

Common questions

Is remote config banned?

No. Content and parameters are fine. Changing the app's core functionality is not.

What about game scripting?

Some educational or game uses are allowed within defined limits.

Can I hotfix a bug remotely?

Ordinary bug fixes ship in updates. Executable remote patching is risky.

Platform rules change often. This page is a plain-language explanation written by AppReviewFix, not official guidance. Check the current App Store Review Guidelines for the exact wording.

Got this exact rejection?Paste it in and get a diagnosis specific to your app, free.
Decode my rejection
Related guidelines
Malware — Malware policyHostile Downloaders — Hostile downloadersDevice Abuse — Device and network abuseSDK Requirements — Third-party SDK compliance2.5.1 — Public APIs only
AppReviewFix
ProductDecoderPricingGuideline library
CompanyAboutFAQContact
ResourcesGuidesTopic overviewsCommon rejection reasons
LegalTermsPrivacy
© 2026 AppReviewFixBuilt by a developer, not a committee.