All guides › By use case
By use caseMobile apps: walk Android and iOS screens like web pages
QAwalk drives the Android emulator over adb and the iOS Simulator, captures each screen with its UI tree, checks labels, touch targets and crashes, and lays the app flow out on the same canvas as your web pages.
Your web flows get reviewed on a canvas. The app ships the same features and nobody sees its screens side by side until the store review. QAwalk walks the app too, so both are reviewed in one place.
The problem
Mobile end-to-end suites prove that a button can be tapped. They do not show whether the screen reads well in Czech, whether a label is cut off on a small phone, or whether the icon button has a label for VoiceOver. Screenshots end up in a chat thread, detached from the criteria.
What changes with QAwalk
The scenario says platform: android or platform: ios. Steps are reached by deep links or by a short step script. Every step becomes a screenshot and a UI tree, criteria are checked against that tree, and the canvas shows the flow with device frames. Reviewers accept or return steps exactly as they do for web runs.
How it works
- Name the app
in
qawalk.config.ymlfor each environment: the Android package (and an APK to install), or the iOS bundle and simulator. - Describe the flow
screens with deep links (
shop://product/42) or scripts such asapp.tap('button[text="Do košíku"]'). Each locale starts the app fresh in that language. - Walk
npx qawalk walklaunches the emulator app or the simulator app. It captures each screen:adb screencapwith the uiautomator tree on Android, andsimctlwith the idb tree on iOS (text recognition without idb). It also reads the Android app log for crashes. - Check
the
apppack checks labels on every control, touch targets (48 dp / 44 pt), truncated texts and crashes. Your own criteria use CSS-like selectors on the tree. Semantic questions read the screen as an outline. - Anything else
real devices, Maestro, Appium, Detox or XCUITest take the screenshot, and
qawalk capture --image shot.png --tree hierarchy.xmlbrings it in with its UI dump.
Skills and prompts
Walk the checkout of our Android app on the emulator in cs and en: product detail by deep link, add to cart, cart. Use the app pack and check the price format.Our Maestro flow already walks the iOS onboarding. After each screen, capture it into QAwalk with the hierarchy, then share the run for design review.Expected outcome: a canvas of app screens in phone frames per locale. Each has its UI tree, highlighted elements for failing criteria (a 30×30 icon button without a label, say) and a crash stamp if the app died.
What you get
- One review surface for web and app: the same canvas, verdicts, comments and history.
- Accessibility basics that are hard to see in screenshots: missing labels and small touch targets, found from the UI tree.
- Language checks per locale: truncated translations and wrong formats are caught on the screen where they happen.
FAQ
Do I need Appium?
No. Android needs adb and an emulator or a device. iOS needs Xcode's Simulator; idb adds the full UI tree and taps. If you already use Appium, Maestro or XCUITest, keep them and import their screens.
Does it work with Flutter or React Native?
Yes, as long as the platform's UI tree exposes the widgets (Flutter with semantics, React Native with accessibility labels). Otherwise QAwalk falls back to text recognition on the screenshot.
Can it run on a real iPhone?
The built-in driver uses the Simulator. For a real device, capture with your tool (XCUITest, Appium) and import the screenshot and page source with qawalk capture --image --tree.