Test automation
Appium
The WebDriver protocol, pointed at native mobile applications.
Appium in practice
A server that accepts WebDriver commands and translates them into whatever the underlying platform actually understands — the XCUITest framework on iOS, UiAutomator on Android. That indirection is the whole design: a suite is written once against a familiar protocol, in a language the team already uses, and the platform-specific machinery stays behind the driver. It automates native applications, the hybrid web views inside them, and mobile browsers, which means one project can cover an app and its responsive site without a second toolchain.
It carries the app half of a mobile testing engagement, usually alongside a WebdriverIO runner so the reporting, retries and parallel session handling arrive assembled rather than hand-built. We reach for it when a client ships a native application whose critical paths — onboarding, payment, offline behaviour — need checking on every release and cannot sensibly be covered by a person doing it manually each time. It is also how a regression suite reaches the platform differences that only appear on real hardware.
The device estate is the real cost, and the tool does nothing about it. Simulators diverge from hardware in exactly the areas that matter — camera, notifications, network transitions, biometrics — and a hosted device cloud is a recurring bill that frequently exceeds the automation effort.
Runs are slow. An indirection layer over a platform framework over an emulator adds latency at every step, and a mobile suite that takes forty minutes changes how often anybody is willing to run it.
Element location is fragile on native views, where there is no equivalent of a stable, developer-assigned test attribute unless the application team agrees to add accessibility identifiers and then keeps them.
Platform upgrades break things on somebody else’s schedule. A new operating system version can invalidate locators and driver behaviour in the same week it ships, regardless of what your team had planned.
It cannot see rendering. The suite confirms that an element is present and interactive; whether the layout is intelligible on a small screen remains a question for a person.
FAQ
Appium questions we hear often
Do we need real devices, or will emulators do?
Both, for different purposes. Emulators are correct for the bulk of functional coverage because they are cheap, parallelise well and reset cleanly. Real hardware is where you verify the things emulation approximates badly: performance on a mid-range handset, behaviour when the network drops mid-transaction, and anything touching the camera or biometrics. A small physical set covering your most common devices alongside a larger emulated tier is the usual arrangement.
Can one suite really cover iOS and Android?
The structure and the test intent are shared; the locators generally are not. Expect a common layer describing what a test does and a thin platform-specific layer describing how each element is found. Teams that insist on total unification end up with conditional logic scattered through the suite, which is harder to maintain than two honest locator sets behind one interface.
How does this fit with a React Native or Flutter app?
It works, with a caveat about identifiers. Cross-platform frameworks render their own component trees, and whether elements arrive with usable accessibility identifiers depends on how the application was built. The practical answer is to agree identifier conventions with the app team before the automation starts, because retrofitting them into a mature codebase is the expensive version of this conversation.
Contact
Wondering if this is the right tool?
Describe what you are trying to verify and we will tell you which instrument fits, including when the answer is one we do not use.