App Store OTA Compliance: Apple & Google Play Guidelines

Introduction

Over-the-Air (OTA) updates are a powerful capability for React Native developers, but they come with compliance responsibilities. Both Apple and Google have specific guidelines about what you can and cannot update outside of their review processes.

This guide is the definitive resource for understanding OTA compliance. We'll cover every rule, every edge case, and every best practice to keep your app in good standing with both app stores.

Disclaimer: This guide is for informational purposes and does not constitute legal advice. Always consult your legal team for compliance decisions specific to your organization.

Apple App Store Review Guidelines

Section 3.3.2: The OTA Rule

Apple's App Store Review Guidelines Section 3.3.2 is the foundational rule governing OTA updates for iOS apps:

"Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS."

Let's break down each clause:

Clause (a): Primary Purpose

Your OTA updates must not change the fundamental nature of your app. If your app is approved as a "fitness tracker," you cannot use OTA updates to transform it into a "cryptocurrency exchange."

• Bug fixes and performance improvements
• UI tweaks and style changes
• New screens within the app's existing purpose
• Updated content and copy
• Feature flags that enable/disable existing features

• Fundamentally changing app functionality
• Adding gambling to a non-gambling app
• Converting a utility app into a social network
• Adding functionality that would have been rejected in review

Clause (b): No Storefronts

You cannot use OTA updates to create a marketplace for downloading other code or applications. This prevents circumventing Apple's App Store as a distribution mechanism.

Clause (c): No Security Bypasses

• No executing arbitrary native code
• No modifying the app sandbox
• No disabling code signing
• No accessing private APIs

React Native JavaScript updates, by their nature, run within the JavaScript engine sandbox and cannot bypass these protections.

Apple's Stance on JavaScript Updates

Apple has historically been permissive of JavaScript updates in hybrid and React Native apps. The JavaScriptCore engine (and now Hermes) runs in a sandboxed environment that cannot access native APIs directly. This is why frameworks like React Native, Cordova, and Ionic have always been allowed to download and execute JavaScript code.

The key principle: JavaScript OTA updates are allowed as long as they stay within the bounds of what JavaScript can do — modify UI, logic, and assets within the existing app shell.

Google Play Developer Program Policies

Google's Approach to OTA

Google Play's policies regarding OTA updates are found in the Developer Program Policies under the "Device and Network Abuse" section:

"An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a WebView or browser)."

The critical exception: JavaScript running in a virtual machine or interpreter is explicitly allowed. React Native's JavaScript engine (Hermes or JavaScriptCore) is exactly this kind of interpreter.

What Google Prohibits

• Downloading and executing native code (.dex, .jar, .so files) outside Play Store
• Side-loading APKs or native libraries
• Using OTA to introduce malware or policy-violating behavior
• Circumventing Play Store billing requirements

What Google Allows

• JavaScript updates via interpreters (React Native, WebView)
• Asset updates (images, fonts, configuration files)
• Feature flags and remote configuration
• A/B testing through JavaScript changes

What JavaScript OTA Updates Can Change

Here's a comprehensive reference of what's OTA-updatable:

Fully OTA-Updatable

Category	Examples
UI Components	React components, screens, modals, forms
Business Logic	Data processing, validation, calculations
Styles	Colors, layouts, fonts, animations
Navigation	Screen flows, deep linking logic
API Integration	Endpoints, request/response handling
State Management	Redux reducers, context providers
Utilities	Helper functions, formatters, parsers
Assets	Images bundled with JS, icons, SVGs
Text Content	Labels, translations, marketing copy
Configuration	Feature flags, thresholds, timeouts

Requires New Binary Submission

Category	Examples
Native Modules	Camera, Bluetooth, biometric custom code
Native Dependencies	New npm packages with native code
Permissions	Camera, location, notifications, contacts
Build Configuration	Info.plist, AndroidManifest.xml changes
App Metadata	App icon, launch screen, display name
Native UI	Native navigation bars, native views
OS Integration	Widgets, extensions, app clips
Minimum OS Version	Raising minimum iOS/Android version

Common Compliance Mistakes

Mistake 1: Changing App Purpose After Approval

A developer submitted a simple calculator app, got it approved, then used OTA updates to transform it into a dating app. This violates Apple Section 3.3.2(a) and will result in app removal.

How to avoid: Only use OTA updates within the scope of your approved app functionality.

Mistake 2: Adding In-App Purchases via OTA

Some developers try to add purchase flows via OTA to avoid Apple's 30% commission. This violates both Apple and Google billing policies and will result in immediate app removal.

How to avoid: All purchase-related functionality should go through the respective store's billing APIs and be submitted for review.

Mistake 3: Downloading Native Code

Using OTA mechanisms to download and load native libraries (.so, .dylib files) is explicitly prohibited by both platforms.

How to avoid: SwiftPatch only handles JavaScript bundles and static assets — native code is never included in OTA updates.

Mistake 4: Ignoring Regional Regulations

Different regions have different requirements. The EU's Digital Markets Act, for instance, has specific provisions about app distribution and updates.

How to avoid: Consult with legal counsel familiar with regulations in your target markets.

Mistake 5: No User Consent

Some jurisdictions require explicit user consent before downloading updates that change app behavior.

How to avoid: Consider implementing an opt-in update mechanism for significant changes.

SwiftPatch Built-in Compliance Safeguards

SwiftPatch includes several features designed to keep you compliant:

1. JavaScript-Only Updates

SwiftPatch physically cannot update native code. The SDK only replaces the JavaScript bundle, making it impossible to violate native code restrictions.

// SwiftPatch only handles JS bundles
SwiftPatch.init({
  deploymentKey: 'YOUR_KEY',
  // Native code is never touched
});

2. Bundle Integrity Verification

Every update is verified against a cryptographic signature, ensuring no tampering occurs between your CI/CD pipeline and the user's device.

3. Audit Trail

• Who deployed the update
• What changed (diff)
• When it was deployed
• How many users received it
• Rollback events

4. Staged Rollouts

Compliance issues can be caught early with staged rollouts. If an update causes unexpected behavior, you can halt the rollout before it reaches all users.

5. Automatic Rollback

If an update causes crashes, SwiftPatch automatically rolls back to the previous stable version, minimizing the blast radius of any problematic update.

Regional Regulations

EU: GDPR Considerations

The General Data Protection Regulation (GDPR) has implications for OTA updates:

• Data minimization: Only collect the data necessary for update delivery
• Transparency: Inform users about OTA update mechanisms in your privacy policy
• Consent: In some cases, you may need user consent for updates that change data processing
• Right to erasure: Ensure update mechanisms respect deletion requests

• No personal data is required for update delivery
• Device identifiers are anonymized
• All data is processed in accordance with GDPR requirements

EU: Digital Markets Act (DMA)

The DMA affects how gatekeepers (Apple and Google) can enforce their update policies. While this primarily impacts the platforms themselves, developers should be aware of evolving sideloading regulations.

US: State Privacy Laws

California's CCPA, Virginia's CDPA, and other state privacy laws have varying requirements. SwiftPatch's minimal data collection approach helps maintain compliance across jurisdictions.

Enterprise Compliance

HIPAA (Healthcare)

For healthcare apps handling Protected Health Information (PHI):

• Ensure OTA updates don't expose PHI during transmission
• Use encrypted channels (SwiftPatch uses HTTPS by default)
• Maintain audit logs of all updates (SwiftPatch provides this)
• Consider self-hosted deployment for full data control

SOC 2

SOC 2 compliance requirements relevant to OTA:

• Security: Bundle signing and HTTPS ensure update integrity
• Availability: Automatic rollback ensures app availability
• Processing Integrity: Differential patching with verification ensures updates are applied correctly
• Confidentiality: All updates are transmitted over encrypted channels
• Privacy: SwiftPatch collects minimal device data

PCI DSS

For apps handling payment card data:

• OTA updates must not introduce vulnerabilities in payment processing
• All update channels must be encrypted
• Maintain logs of all code changes
• Implement access controls for deployment

SwiftPatch supports role-based access control for deployment permissions, ensuring only authorized team members can push updates to production.

Audit Trail Requirements

For regulated industries, maintaining a comprehensive audit trail is essential:

# View deployment history
swiftpatch deployments --limit 50

# Export audit log
swiftpatch audit-log --format csv --from 2026-01-01 --to 2026-02-13

# Get detailed deployment info
swiftpatch deployment-info --id dep_abc123

• Deployment ID and timestamp
• Deployer identity (authenticated via API key or SSO)
• Platform and target environment
• Rollout percentage
• Bundle hash and signature
• Rollback events with reason
• User adoption metrics

FAQ: OTA Compliance

Q: Can Apple reject my app for using OTA updates?

A: No, as long as you follow Section 3.3.2. JavaScript OTA updates are explicitly allowed. Thousands of apps use this capability without issue.

Q: Do I need to mention OTA updates in my App Store description?

A: No. OTA updates are a standard technical capability and don't need to be disclosed in your App Store listing. However, you should mention them in your privacy policy.

Q: Can I use OTA to bypass App Review for a feature Apple would reject?

A: Absolutely not. Using OTA to circumvent App Review is a violation and will result in app removal and potential developer account termination.

Q: Do OTA updates count against my app's storage on the device?

A: SwiftPatch's differential patches are extremely small (200KB average). The updated bundle replaces the previous one, so there's minimal additional storage impact.

Q: Is OTA compliant for government apps?

A: It depends on the specific government regulations. SwiftPatch's self-hosted option meets FedRAMP-adjacent requirements, but consult your compliance team for specific guidance.

Q: How does SwiftPatch handle data residency?

A: SwiftPatch cloud uses global CDN with configurable regions. For strict data residency, use SwiftPatch's self-hosted option to keep all data within your jurisdiction.

Q: Can I use OTA updates for apps in China?

A: China has specific regulations about app updates. OTA JavaScript updates are generally permitted, but consult local legal counsel for guidance on your specific use case.

Conclusion

OTA updates for React Native are fully compliant with both Apple and Google's guidelines when implemented correctly. The rules are straightforward: update JavaScript and assets, don't change your app's fundamental purpose, and don't bypass platform security.

SwiftPatch is built with compliance at its core — JavaScript-only updates, bundle signing, audit trails, and staged rollouts all work together to keep your app in good standing.

Stay compliant. Ship faster.

Get started with SwiftPatch →