Generally no. Apple's App Review Guidelines, section 2.5.2, say apps must be self-contained in their bundles and may not download, install or execute code that introduces or changes the app's features or functionality, including code from other apps. A narrow exception exists for educational apps that teach or test executable code.
What the rule says
The guideline text, as published, has three parts:
- Apps must be self-contained in their bundles.
- They may not read or write data outside their designated container.
- They may not download, install or execute code that introduces or changes features or functionality.
The exception is limited. Educational apps that teach or let students test executable code may download code in narrow circumstances, provided the code is not used for other purposes and the app makes the source code completely viewable and editable by the user.
Why a store would want this
Review looks at the app as submitted. If an app could pull in new behaviour afterwards, the reviewed version would tell you little about what runs on a phone next month. The rule keeps the reviewed bundle and the running software the same thing, which is a basic integrity property.
It is the same idea behind remote code limits in browser extension stores. Different platform, same logic: reviewers can only judge what they can see.
What this means for plugin and extension designs
If you run a product with a plugin ecosystem and want an iOS app, think carefully:
| Design | Fits the rule? | Notes |
|---|---|---|
| Fixed feature set, configuration from a server | Usually | Data may change behaviour only within what shipped |
| Plugins as downloadable executable code | Risky | Likely to conflict with 2.5.2 |
| Plugins run on your server, app shows results | Usually | Logic stays server side |
| User can write and run their own code in an educational app | Narrow exception | Source must be viewable and editable |
This table is a reading aid, not legal or policy advice. Check the current guideline text and ask Apple through App Review when a design is borderline.
Security reasons to follow the spirit even where allowed
Even outside iOS, shipping code you cannot inspect after the fact weakens your controls. For any app or plugin platform:
- Keep executable logic in the signed package.
- Treat remote configuration as data, validate it, and limit what it can toggle.
- Log which configuration version each client used.
- Have a way to revoke or block a version centrally.
Privacy rules often reviewed alongside
Section 5.1 requires a privacy policy, consent for data collection, and data minimisation. Apps that collect user or usage data must obtain consent, even if the data is anonymous at collection, and paid functionality must not depend on granting access to that data. Reviewers apply these together with 2.5.2, so a feature that downloads code and also collects data faces two questions.
A note for vendors who ship SDKs
If your SDK fetches and runs remote logic, every app that embeds it inherits the problem. Apple's guidance says you are responsible for all code a third-party SDK includes in your app. Document what your SDK downloads, and why, so customers can answer the question themselves.
Safeguard's SBOM and dependency scanning can list the third-party SDKs in your mobile builds, which is the first step in answering what each one downloads.
Quick check
Can a mobile app update its feature set from a server?
Configuration and data are different from code. The guideline prohibits downloading or executing code that introduces or changes features.
Is there an exception?
Yes, a narrow one for educational apps that teach or test executable code, with source fully viewable and editable by the user.
Does this apply to my SDK?
An app is responsible for the code its SDKs include, so SDK behaviour can put the host app at risk of review problems.
Sources
Last reviewed: 19 October 2026.
