OTA or hot code push does not materially change app functionality

Apple's guideline 2.5.2 prohibits apps from downloading executable code after approval. Using OTA updates (Expo Updates, CodePush) combined with remote feature flags to silently enable entirely new functionality — gambling, payments, adult content, cryptocurrency — after passing review is treated as deception and results in account termination, not just app rejection. The line Apple draws is between bug fixes and UI changes (permitted) and new features that would require re-review (prohibited). The combination of OTA + remote config is the mechanism most commonly exploited to bypass review — reviewers know what to look for.

Configure Expo Updates to apply only on error recovery, and ensure no remote flag can enable a feature category that wasn't present and reviewed at submission time.

// app.json
"updates": {
  "enabled": true,
  "fallbackToCacheTimeout": 0,
  "checkAutomatically": "ON_ERROR_RECOVERY"
}

Audit every LaunchDarkly/Statsig/GrowthBook flag in the codebase. For any flag that controls a payment flow, adult content, gambling mechanic, or cryptocurrency feature — verify that feature was present and reviewable at the last App Store submission. Disable the flag permanently or submit a new app version before enabling it.

• ID: no-hot-code-push-abuse
• Severity: info
• What to look for: Count all relevant instances and enumerate each. If Expo Updates or CodePush was detected, examine how OTA updates are configured. Check app.json for updates.url and updates.enabled. Look for expo-updates runtime API usage: Updates.checkForUpdateAsync(), Updates.fetchUpdateAsync(), Updates.reloadAsync(), CodePush.sync(). Look for conditional logic that loads different feature sets based on remote config values fetched alongside or through the update mechanism. Pay special attention to expo-updates combined with remote feature flags that could enable major new features post-approval. Check if the OTA mechanism is used to ship JavaScript-only UI and logic changes (permitted) vs. changes to core functionality that would require re-review (not permitted).
• Pass criteria: OTA updates, if present, are used for bug fixes and minor UI changes only. At least 1 implementation must be verified. There is no mechanism to enable substantially new features or policy-violating behavior via OTA post-approval.
• Fail criteria: OTA update configuration combined with remote feature flags or remotely-fetched code paths that could enable substantially different app behavior without re-review; REQUEST_INSTALL_PACKAGES Android permission combined with self-update logic.
• Skip (N/A) when: No OTA update mechanism (no expo-updates, no react-native-code-push, no custom OTA logic) is present in the codebase.
• Detail on fail: "expo-updates combined with remote feature flags could enable new payment flows post-approval without re-review" or "CodePush.sync() configured to apply mandatory updates immediately — could push major feature changes"
• Remediation: Both Apple and Google allow OTA updates for bug fixes and minor changes, but prohibit using them to add major new functionality that bypasses review.
  1. Configure Expo Updates for user-prompted updates (not forced):

     "updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_ERROR_RECOVERY" }
     

  2. Do not combine OTA with remote feature flags that enable entirely new app screens or payment flows
  3. Use OTA updates for: bug fixes, copy changes, minor UI tweaks
  4. Submit a new App Store release for: new screens, payment changes, new permissions, core feature additions