Skip to main content
Version: 4.4.x.x RR (Android, iOS) / 4.5.x.x RR (Flutter) / 5.x.x.x RR (React Native)

General Publication Hints

Testing release builds during development

When testing a release build on a physical device before submitting to an app store, the way the build is deployed matters.

Deploying a release build directly from an IDE or via a CLI command while the device is connected via USB — for example with flutter run --release, an Xcode run scheme, or Android Studio's run action — keeps developer tooling (debugger, profiler, instrumentation framework) attached to the app process. The release SDK includes a debugger detection guard and related tamper guards that are intentionally not present in the debug flavor. When any of these guards fire, the SDK throws DeviceProtectionError and the app does not initialize.

A common symptom is that the app works in debug mode, fails in release mode on a directly-connected device, and then works again after installing the same release build through a distribution channel.

✅ How to test a release build correctly

Distribute the release build through a channel that installs the app without attaching developer tooling:

  • iOS: Use TestFlight or export an ad hoc IPA and install it via Xcode or Apple Configurator.
  • Android: Build the APK and install it via adb install <app>.apk — this installs the app without keeping the process attached — or use Firebase App Distribution.

See Troubleshooting: DeviceProtectionError when testing a release build on a physical device if you have already encountered this error.

Rejection because of crash (simulator / emulator)

It may happen that your app is rejected during the publication review. The usual root cause is that Google or Apple reviewers are trying to test the app on a simulator or emulator. As the release SDK actively prevents this, a crash in this case is intended behaviour.

We recommend explicitly stating that the security features of the app prevent it from being run in an emulator or simulator and the app crash in this scenario is deliberate and intended as part of the test information provided to the Apple or Google testers.

In case the app is rejected you have a chance to appeal the rejection and mention the intended behaviour again in the appeal note.