FAQs

You can push via OTA:

• JavaScript bundle changes
• Static assets - images, fonts, audio, video
• Bug fixes, UI changes, and JavaScript-level changes that stay within your app's intended and advertised purpose

You cannot push via OTA:

• Native code or native module changes
• New device permissions
• Changes that fundamentally alter the app's core purpose
• Anything requiring a binary rebuild or new SDK version

See the Apple App Store Review Guidelines and Google Play Developer Policy for the authoritative platform rules.

The permission comes from the Apple Developer Program License Agreement, section 3.3.1(B) (Executable Code): interpreted code may be downloaded to an app so long as it:

• Does not change the app's primary purpose by providing features or functionality inconsistent with its intended and advertised purpose
• Does not bypass signing, sandbox, or other security features of the OS
• Does not create a store or storefront for other apps

App Store Review Guideline 2.5.2 is the matching restriction: an app may not download, install or execute code that introduces or changes features or functionality. Read together, the line Apple draws is your app's advertised purpose, not the size of the change.

You cannot push native code, new entitlements, or changes that would require App Store re-review. DeployPulse signs releases with RS256 so your app can verify an update came from you; that is our integrity feature, not an Apple requirement.

Google Play's Device and Network Abuse policy bars an app from updating itself outside Google Play, then carves out an exception: the restriction does not apply to “code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs”. A React Native JavaScript bundle runs in exactly that kind of interpreter. The policy does not permit:

• Replacing or updating the APK/AAB outside of Google Play
• Downloading native libraries (.so files) not included in the original package
• Delivering functionality that itself violates Google Play policies

React Native JavaScript bundle updates fall within the permitted interpreted code category and are safe to push via DeployPulse.

Yes. DeployPulse supports Expo in two ways:

• Expo CNG (bare workflow) - apps using the @deploypulseio/react-native-code-push SDK work exactly like standard React Native apps. Its Expo config plugin sets up the native files at prebuild time, and DeployPulse is already its default server.
• Expo Updates v1 protocol - managed and bare workflow apps using the expo-updates package are supported natively. Point your updates.url at DeployPulse and push releases with dpctl release-expo - no CodePush SDK required.

See our Expo setup guide for full instructions.

Code signing is optional but strongly recommended, particularly on iOS where Apple's guidelines encourage it for interpreted code updates.

DeployPulse supports RS256 JWT code signing:

• Generate an RSA key pair with dpctl app set-public-key
• The CLI signs each release bundle at upload time using your private key
• DeployPulse verifies the signature server-side before accepting the release
• The CodePush SDK verifies the signature on-device before applying the update

See our code signing guide for setup instructions.

DeployPulse has two safeguards:

• Auto-rollback - monitors the error rate on every new release. If it exceeds a configurable threshold (e.g. 5%) within a configurable time window, DeployPulse automatically rolls back to the previous stable release and notifies you by email. Configured per deployment in the dashboard.
• Manual rollback - roll back any release at any time from the Deployments page in the dashboard or via dpctl rollback <app> <deployment>.

Gradual rollouts (e.g. 10% of users first) are also supported and are a good way to catch issues before they reach your full user base.

Email support@deploypulse.io with bug reports or feature requests. We appreciate the feedback.