Test Execution
Mobile App Testing
Upload an Android APK or iOS IPA and AegisRunner explores it on a real device, generates test cases, runs them, and reports crashes, accessibility, performance, dead controls and visual regressions.
Last updated: June 30, 2026
Mobile App Testing
AegisRunner tests native mobile apps with the same scan → generate → run flow it uses for the web. You upload an Android .apk or iOS .ipa; AegisRunner installs it on a real device, explores it autonomously screen by screen, generates replayable test cases from what it found, and runs them back on a real device — surfacing crashes, accessibility issues, performance problems, dead controls and visual regressions along the way.
Supported platforms
| Platform | Upload | Runs on |
|---|---|---|
| Android | .apk | Real device cloud, or a fast Android emulator |
| iOS | .ipa | Real device cloud |
Starting a mobile scan
- Open the scan modal and choose Test a mobile app.
- Upload your
.apkor.ipa(or paste a hosted URL to the build). - Pick a device and OS version from the live device list (e.g. Pixel 7 / Android 14, iPhone 14 / iOS 17), or leave it on Auto to let AegisRunner pick an available one.
- Start the scan. AegisRunner installs the build, launches it, and explores — opening screens, filling and submitting forms, and backtracking to reach every section.
You watch progress live in the Activity panel (“Exploring on device…”), the same place web scans report. When exploration finishes, AegisRunner generates a test suite from the trace and the screens land in the scan result, each with a screenshot.
What it detects
While exploring, AegisRunner runs a set of mobile-native checks and files anything it finds as Issues — alongside the web issue types — so the Issues lens is one place for everything.
| Detector | What it catches |
|---|---|
| Crashes | The app dying mid-flow — caught from the system crash dialog and the device log (fatal exceptions, “App Not Responding”). Each crash is attributed to the exact action and screen that triggered it (“after tapping ‘Submit’ on Checkout”). |
| Native exceptions & ANRs | Runtime exceptions and Application-Not-Responding events pulled from the device log, including background ANRs that never show an on-screen dialog. |
| Accessibility | Unlabeled controls (no screen-reader name), touch targets smaller than 48dp, duplicate labels, redundant role words (“Submit button”), overlapping controls, and low color contrast (below 3:1). |
| Performance | App cold-start time (true time-to-first-display from the system, not a wall-clock guess) and screens that get stuck loading (a spinner that never resolves). |
| Dead controls | Buttons and controls that do nothing when tapped — no navigation, no dialog, no state change. The hardest class of bug to find with crash logs alone, and one automated crawlers usually miss. |
| Visual regression | Screens that look different from your previous scan. The diff is layout-aware: changing data inside a stable layout won’t false-alarm; a real layout shift will. |
Running the generated tests
The generated suite behaves like any other in AegisRunner — open it under the project’s Tests and hit Run. The run executes on a real device, replaying the recorded steps and assertions. Mobile and web suites are clearly marked (📱 / 🌐) everywhere they appear, so a mixed project stays readable.
Cross-platform tests
AegisRunner can author a single journey that spans mobile and web — for example, create a record on the phone app and assert it appears in the web admin, or vice versa. Each step carries its own platform, and AegisRunner routes it to the right engine: mobile steps run on a device, web steps run in the browser, all within one test.
Start one from the scan modal’s cross-platform option by giving the web URL and the app — AegisRunner grounds a sync journey in your actual screens and persists it as a cross-platform suite you can run on demand.
Plans
Mobile and cross-platform testing are Pro and above. On Free and Starter the scan modal shows web scanning only; mobile options appear once you’re on a qualifying plan. Mobile runs draw from the same monthly usage budget as web runs — see Usage & Billing.
Common questions
Which devices and OS versions can I pick?
The device dropdown is populated live from the available real-device pool, filtered to your chosen platform, so it always reflects what’s currently bookable. Android can additionally run on a fast emulator if you don’t need a specific physical device.
Does iOS work the same as Android?
Yes — upload an .ipa, pick an iPhone and iOS version, and the same explore → generate → run flow applies. Some device-log-based detectors (crash attribution, ANRs, cold-start timing) are richest on Android, where the system log is most detailed.
What file types are accepted?
Android .apk and iOS .ipa. You can upload the file directly or point AegisRunner at a hosted URL for the build (handy for CI artifacts).
Do I need to write any device automation code?
No. Exploration and test generation are autonomous — you provide the build and pick a device. The generated tests are editable afterward like any AegisRunner test.
Related
- Starting a New Scan — the web equivalent of a mobile scan.
- AI-Powered Test Generation — how tests are generated from exploration.
- Running Tests — running and reading test results.
- Subscription Plans — where mobile testing unlocks.
Was this helpful?