# Guideline 2.5.2 - Software Requirements: Code Injection or Hot-Patching

**Guideline:** 2.5.2 · **Store:** Apple App Store · **Severity:** high · **Fix difficulty:** hard · **Typical turnaround:** 1-3 days

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-252-software-requirements-code-injection-or-hot-patching

## Description

Apple is rejecting your app because it downloads and executes code that was not included in the original binary submitted for review. This covers JavaScript-to-native bridges that execute arbitrary native code, hot-patching frameworks like JSPatch or Rollout, and any mechanism that can modify the app's native behavior after Apple has approved it. This is one of Apple's hardest lines. The reasoning is straightforward: Apple reviews a specific binary and approves it. If the app can download code that changes its behavior after approval, Apple's review is meaningless. This guideline was created largely in response to JSPatch, which was widely used in the Chinese developer community to push native code changes without going through App Store review. Important nuance: JavaScriptCore and WKWebView can execute JavaScript, and that's fine -- Apple's concern is specifically about JavaScript (or any other code) that bridges to native APIs in ways that weren't present in the reviewed binary. React Native and similar frameworks are generally acceptable because the JavaScript they execute interacts with a fixed set of native bridges that were reviewed. But dynamically downloading new native bridge code is not acceptable.

## Common variations

- App contains code that can modify behavior after review
- App uses hot-patching framework to push code changes
- App downloads and executes code not in original binary
- App uses JSPatch, Rollout, or similar code injection framework
- App can load and execute dynamic native code from a server

## Example rejection email

```
Guideline 2.5.2 - Performance - Software Requirements

Your app contains code that can modify the app's behavior or functionality after App Store review, which is not in compliance with the App Store Review Guidelines.

Specifically, the app uses a framework that enables the downloading and execution of code not included in the app's original binary.

Next Steps:
Please remove all code, frameworks, or SDKs that allow the downloading and execution of code that can change the app's behavior or functionality. Note that apps may use embedded interpreted code (such as JavaScript in JavaScriptCore) only if the scripts are bundled with the app and are not downloaded.
```

## Resolution steps

## Quick Assessment
- **Risk level:** High
- **Resolution path:** Fix & Resubmit
- **Typical turnaround:** 1-3 days

## The Fix

1. **Remove hot-patching frameworks** -- If you're using JSPatch, Rollout, or any similar SDK, remove it entirely from your project. There is no compliant way to use these.

2. **Audit dynamic code loading** -- Search your codebase for: `NSClassFromString`, `performSelector`, `dlopen`, `dlsym`, `objc_msgSend` with dynamic selectors, and any code that evaluates strings as code (`eval()` equivalents).

3. **Bundle all JavaScript locally** -- If you use JavaScriptCore or any embedded JavaScript, all scripts must be bundled with the app binary. They cannot be downloaded from a server. Use CodePush or similar OTA update systems with extreme caution -- Apple allows updating JavaScript bundles only if the updates don't change the app's primary purpose or create a 'store within a store.'

4. **Check third-party SDKs** -- Some analytics, A/B testing, or feature flagging SDKs use code injection internally. Audit them and replace any that download executable code.

5. **Document your architecture** -- In review notes, explain how your app uses JavaScript (if applicable) and confirm that all code was included in the submitted binary.

## Prevention
- Never use hot-patching frameworks
- Bundle all interpreted code with the binary
- If using CodePush or similar OTA JavaScript updates, ensure updates don't change core functionality
- Audit all third-party SDKs for dynamic code loading behavior

## Appeal guidance

If your app uses React Native, Flutter, or a similar cross-platform framework and Apple flagged it incorrectly, explain that the JavaScript/Dart code interacts only with a fixed set of native bridges that were included in the reviewed binary. Provide documentation of your framework's architecture.

## Before / after examples

**Before:** App includes JSPatch framework that downloads JavaScript patches from a server and converts them to native Objective-C method calls at runtime
**After:** JSPatch completely removed. All bug fixes and updates are delivered through standard App Store review process. JavaScript used only in bundled WKWebView content.
**Why it works:** There is no compliant version of hot-patching native code. The only path forward is complete removal and committing to the App Store update process.

## Common questions

**Can you appeal a 2.5.2 rejection?**

If your app uses React Native, Flutter, or a similar cross-platform framework and Apple flagged it incorrectly, explain that the JavaScript/Dart code interacts only with a fixed set of native bridges that were included in the reviewed binary. Provide documentation of your framework's architecture.

**How long does this typically take to fix?**

Typical turnaround is 1-3 days (difficulty: hard). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-252-software-requirements-code-injection-or-hot-patching*