.app (iOS), upload it to a channel/tag,
run momentic-mobile.
Produce a testable build
- Android (APK)
- iOS (simulator .app)
The Gradle project lives in For a faster debug build during authoring,
android/:./gradlew assembleDebug works too:
debug builds are debuggable=true and need no extra configuration.Upload and run
Add the CLI as a dev dependency so the lockfile pins the version in CI:smoke.test.yaml
Local for a local instance.
React Native pitfalls
- Hermes and release-mode JS. The tested build is the compiled native app. JS-only changes (a moved button, a renamed screen) require a rebuild for the installed binary to reflect them.
- Metro is optional. A release APK embeds the JS bundle, so it needs no Metro server. A dev build that looks for Metro will hang at the loading screen if Metro is not running; test release/preview builds unless you specifically want dev-server coverage.
testIDbecomes an accessibility identifier. React NativetestIDprops surface to the native layer, sotap: the element with testID loginworks. But prefer describing what the user sees; targets survive refactors that change IDs.- Third-party native modules (maps, cameras, Bluetooth) behave as they do on
any emulator. Simulated camera/microphone input is available through
setCamera/setMicrophonewhere supported; some hardware-backed features have no emulator equivalent. - WebView content on Android needs
WebView.setWebContentsDebuggingEnabled(true). - Deep links open via an
appiumstep (mobile: deepLink).
In CI
.github/workflows/mobile.yml
--channel/--tag on run select the asset this job just uploaded; tests’
defaultChannel/defaultTag only apply when the flags are absent. iOS builds
need a macOS runner (runs-on: macos-latest) and an
xcodebuild build-for-testing step before upload.
Related
- Android app setup
- iOS app setup
- Expo guide for the Expo-managed workflow
- Emulators and simulators