Autosana runs your mobile apps on both our virtual device cloud (iOS Simulators and Android Emulators) and real devices in the cloud. The build you upload decides where it can run:
Architecture: a universal APK/AAB (recommended) runs on both emulators and real devices. An x86_64-only APK runs on emulators but not real devices.
Most build commands create universal APKs that include all architectures by default, so the same Android build works on both emulators and real devices — no separate build needed.
Select your framework to see build instructions:
React Native
Flutter
Native iOS
Native Android
Important: React Native apps must be built in Release mode. Debug builds will attempt to connect to Metro bundler and fail to run on the device. Release builds bundle the JavaScript code directly into the app, making them standalone.
eas build --platform ios --profile autosana-simulator
Once the build completes, EAS will provide a download URL for the build
Download and extract it to get the .app file
Compress the .app to a .zip and upload it to Autosana
This profile only creates a Simulator artifact; it does not enable APNs. If
the app uses expo-notifications, add its config plugin. During Expo Prebuild
or Continuous Native Generation, that plugin adds
aps-environment=development to the iOS app. If the app does not use
expo-notifications, declare the entitlement under ios.entitlements or
configure it in the native Xcode project. Follow Testing Push Notifications:
Configure an Expo EAS
build.
The output must contain aps-environment with the value development. Then run the complete architecture, entitlement, and bundle-ID preflight in Testing Push Notifications, compress the .app, and upload the resulting .zip.
Why Release configuration? Release builds provide production parity with
optimizations enabled, matching what your users experience. Debug builds work,
but they are not recommended because they do not reflect the production
environment.
Release builds provide better production parity but require signing configuration.Step 1: Configure Signing (if not already set up)Add this to your app/build.gradle:
android { buildTypes { release { // Use debug keystore for testing (not for Play Store) signingConfig signingConfigs.debug minifyEnabled false } }}
This uses the debug keystore for convenience. For Play Store releases, you’ll need a proper release keystore.
Step 2: Build the Release APKUsing Terminal:
cd /path/to/your/android/project./gradlew assembleRelease
To run on real iPhones instead of the simulator, upload an .ipa built for physical hardware (iphoneos) — not a zipped .app. The file extension is how we route the build: .ipa → real device, .app / .zip → simulator.
Signing matters. Use a Development or Ad Hoc signed .ipa. You do not need to register our device UDIDs — builds are automatically re-signed for the test device. Enterprise-signed builds fail to launch on our devices, and App Store builds aren’t supported. Re-signing strips some entitlements (e.g. Push Notifications, Apple Pay, App Groups), so features depending on them won’t work during tests.
If re-signing breaks Team-ID-prefixed Keychain access groups, expand Advanced during IPA upload and enable Fix Keychain access after re-signing. Most apps do not need this option.
Android needs no separate build — a universal .apk / .aab already runs on both emulators and real devices.
React Native (Expo)
Flutter
Native iOS / bare React Native
Use an EAS profile with internal distribution — note there is nosimulator: true:
The .ipa lands in ./build/ipa/. Upload it to Autosana.
After uploading your .ipa, start a run with Target: Real device (or physical_device: true via the API). See Real Device Testing for how to run and pick a device.
Was this page helpful?
⌘I
Assistant
Responses are generated using AI and may contain mistakes.