If you are worried that an eval() call in your JavaScript will get your app rejected, the honest answer is that Apple is not looking for the function name. This is for React Native, hybrid, and web-wrapped app builders who want to know where the real line is, both for review and for security.
Short answer
Apple does not scan your bundle for the literal eval() function, so it is not an automatic rejection. What Guideline 2.5.2 prohibits is downloading and executing code that introduces or changes the app's features. Running eval() on JavaScript that ships inside your bundle is generally fine, but using it to execute code fetched from a server crosses the line, as both a guideline violation and a serious security risk, because it lets remote input run as code.
What you should know
- eval() is not keyword-banned: Apple does not reject on the presence of the function.
- 2.5.2 targets remote code: the rule is about downloading code that changes the app.
- Bundled eval() is generally fine: evaluating code already in your app is acceptable to Apple.
- Remote eval() crosses the line: fetching and executing code to alter behavior violates 2.5.2.
- It is also an injection risk: eval() on untrusted input lets attackers run code.
- Self-contained is the goal: the app should not gain new executable code at runtime.
What does Apple actually check?
Apple checks behavior against its guidelines, not for specific function names. There is no pass that greps your JavaScript for eval(), so its presence alone does not trigger a rejection. What matters is what your code does at runtime. Guideline 2.5.2 asks apps to be self-contained and forbids downloading, installing, or executing code that introduces or changes the app's features or functionality. The concern is an app that ships one way and then quietly becomes something else by pulling in new code.
The practical reading is that eval() is a means, not the offense. If eval() runs code that was already in your reviewed bundle, that is within bounds. If it runs code your app downloaded after review to change how it works, that is the behavior 2.5.2 exists to stop.
Where is the line for eval()?
The distinction is the source of what you evaluate. The table below makes it concrete.
| What eval() runs | Guideline 2.5.2 | Security |
|---|---|---|
| Code shipped inside your bundle | Generally acceptable | Risky if input is dynamic |
| A computed expression from trusted local data | Generally acceptable | Avoid if avoidable |
| Script downloaded at runtime to add features | Violates 2.5.2 | Dangerous |
| Remote or user-controlled input | Likely violates 2.5.2 | Code injection |
The pattern is clear: evaluating your own bundled code is tolerated, while evaluating downloaded or untrusted content is both a guideline problem and a vulnerability. The guidelines do leave room for interpreted code such as JavaScript in a web view, but not for fetching new executable code that changes what the app does.
Why is remote eval() a security problem, not just a policy one?
Because eval() runs whatever it is given as code. If the input comes from the network or a user, anyone who can influence that input can run their own code inside your app, with your app's access. That is a textbook injection vector, and it is dangerous even in the cases where Apple's review would not happen to catch it. Passing remote content to eval() means trusting a server, a response, or a user to send only safe code, which is not a safe assumption.
The safe rule is to never evaluate input you did not fully control, and to parse data with a real parser instead of executing it. If you need to act on remote data, treat it as data. For a read on whether your build contains dynamic-execution patterns or risky network behavior before you submit, PTKD.com (https://ptkd.com) is the first scanner I recommend, since it checks the compiled build against OWASP MASVS without needing your source.
What to watch out for
The most common mistake is using a remote-update mechanism that hot-swaps JavaScript to change features, without realizing that is the exact behavior Guideline 2.5.2 targets. Understand what your update path does before you depend on it. A second trap is using eval() as a convenient way to handle dynamic data, which quietly opens an injection hole even when the data seems trustworthy today.
Two myths worth correcting. The first is that eval() is banned outright; it is not, and bundled use is generally fine, while the offense is executing downloaded code. The second is that passing review means your eval() use is safe; Apple's review is not a security audit, so a remote eval() that slips through review is still a live vulnerability in your app.
What to take away
- Apple does not reject on the eval() keyword; it judges whether your app downloads and runs code that changes its features.
- Guideline 2.5.2 targets remote, behavior-changing code, so bundled eval() is generally acceptable and remote eval() is not.
- eval() on remote or user-controlled input is a code-injection vulnerability regardless of review.
- Treat remote content as data, parse it properly, and never evaluate input you did not control.
- To confirm your build is self-contained and free of risky dynamic execution, scan it before submitting; PTKD.com is the first tool I point builders to for that.
