Appium Interview Questions

"My test uses a client library, say the Java client. When I call click, the client turns it into a W3C WebDriver HTTP request and sends it to the Appium server, which is a Node.js process listening on port 4723 by default. The server looks up my session and passes the command to the driver the session was created with, for example UiAutomator2 on Android. That driver has already installed a small helper server on the device, and it forwards the command there. On Android the helper uses Google's UiAutomator framework to find the element and tap it. On iOS the XCUITest driver does the same through WebDriverAgent, which is built on Apple's XCTest. The result comes back the same way as a JSON response. Knowing this chain helps me debug, because a failure can sit in my code, the server, the driver or the helper on the device."

"Appium 1 shipped with every driver bundled into the server. From Appium 2 the server is just the core, and drivers are installed separately, a bit like packages. I run appium driver install uiautomator2 or appium driver install xcuitest, and appium driver list shows what's there. The nice part is I can update the iOS driver without touching Android, and pin versions per project. Plugins are the other idea: they change server behaviour without a new driver. Image-based element finding, for example, moved into a plugin, and I switch plugins on when I start the server. Two things caught teams out when they migrated. The default base path changed from /wd/hub to just the root, so old server URLs stopped working. And any capability that isn't a W3C standard one needs the appium: prefix."

"UiAutomator2 is black box. It drives the phone the way a user would, from outside the app, so it works on any build you can install, including a release build, and it can reach things outside the app like the notification shade, system settings or a permission dialog. That makes it the default for most teams. Espresso is grey box. The Espresso driver builds a server that runs inside the app's own process, so it knows when the main thread is idle and waits automatically. Tests tend to be faster and less flaky, and it can reach app internals. The cost is setup: that server has to be built to match the app and signed with the same key, and it's mostly limited to what's inside the app. I'd pick Espresso when the team owns the app build and speed matters, UiAutomator2 for end-to-end flows across system screens."

"WebDriverAgent is the helper the XCUITest driver puts on the device. It's an XCTest runner app, built with xcodebuild, and it starts a small HTTP server that receives commands and drives the UI through Apple's XCTest APIs. On a simulator that just works. On a real iPhone the first run usually fails for a few reasons. WDA has to be signed with an Apple developer team and a provisioning profile that includes the device, so I pass the team and signing identity in the capabilities, and sometimes a unique bundle ID for WDA. On the phone, depending on the account type, I may need to trust the developer in Settings, and on newer iOS versions Developer Mode must be switched on. And the first build is slow enough to hit launch timeouts. Once it works, I prebuild WDA and reuse it, so later sessions start in seconds instead of rebuilding."

"Not locally. The XCUITest driver needs macOS with Xcode installed, because WebDriverAgent is built with Xcode's tools and iOS simulators only run on a Mac. Android is more relaxed: Windows, Mac or Linux all work, as long as the Android SDK is installed, adb can see the device, and the environment variables for the SDK and Java are set. But the test code itself doesn't have to run on a Mac. My tests only send HTTP requests, so I can write and run them from Windows and point them at an Appium server on a Mac in the office or in CI, or at a cloud device farm that provides iOS devices. When setting up a new machine I run the driver's doctor check, which lists anything missing before I waste time on a failing session."

"At minimum I need platformName set to Android and automationName set to UiAutomator2, because together they tell the server which driver to use. On Android, appium:deviceName is mostly a label. What really picks the device when more than one is connected is appium:udid, the serial that adb devices prints. Then the app, either appium:app pointing to an APK, or appPackage and appActivity for an app that's already installed. I usually add appium:newCommandTimeout so a long debug pause doesn't end the session. The prefix is because Appium follows the W3C WebDriver standard, which only defines a handful of capabilities, like platformName and browserName. Anything vendor-specific must carry a prefix, so Appium's own ones are written appium:something. In Java I use the UiAutomator2Options class, which sets platform and driver for me and adds the prefixes automatically."

"With noReset set to true, Appium leaves the app and its data alone between sessions, so if the last test logged in, the next one starts logged in. It's fast, but tests start depending on each other. With fullReset set to true, the app is uninstalled and installed fresh, which gives a clean slate but costs time on every session. If you set neither, the driver does a middle-ground reset that differs between Android and iOS, so I don't rely on the default. What I do is decide state explicitly. I install fresh once per suite, then between tests I clear the app's data or terminate and relaunch it, depending on what the test needs. And for setup like being logged in with items in a cart, I create that through a backend API or a deep link, not by tapping through five screens each time."

"I pass appium:app when I want Appium to install the build for me, which is the normal case in CI: it points to an APK for Android, or on iOS a .app for a simulator or an IPA for a real device, and it can be a local path or a URL. When the app is already on the device, say installed by the team or from a store for a smoke test, I skip the file and tell Appium what to launch: appPackage and appActivity on Android, and bundleId on iOS. To find the package and activity I open the app and ask adb which window has focus. One thing that trips people up on iOS: a build made for the simulator won't install on a real phone, and a real-device build has to be signed for that device."

"For most tests the dialog is noise, so I remove it up front. On Android I set appium:autoGrantPermissions, which grants the runtime permissions the app declares when Appium installs it, or I grant specific ones with adb before the test. On iOS I can set appium:autoAcceptAlerts or autoDismissAlerts, and the XCUITest driver can also accept a system alert directly from code, the same way you'd accept a browser alert. But I don't want to hide the dialog everywhere, because the permission flow is a real feature. So I keep a few dedicated tests with permissions not granted: one that allows and checks the feature works, and one that denies and checks the app degrades gracefully, like showing a message instead of crashing."

"Appium supports accessibility id, id, class name and XPath on both platforms, plus native strategies: the UiAutomator selector on Android, and predicate strings and class chains on iOS. Image matching is available through a plugin. My first choice is accessibility id, because it works across both platforms: on Android it matches content-desc, on iOS the element's name, which usually comes from the accessibility identifier the developers set. On Android I'm also happy with a stable resource-id. When I need to match on more than one attribute, I use the native strategies, a UiSelector on Android or a predicate or class chain on iOS, because the platform evaluates them directly. XPath is my last resort. It's slow on mobile and it breaks when the layout shifts. And where the app has no good IDs, I ask the developers to add them rather than building clever XPaths."

"Mobile platforms don't have an XPath engine built in. To answer an XPath query, the driver has to take a snapshot of the whole UI hierarchy, turn it into XML, and then search that XML. On a big screen with long lists, especially on iOS where building that snapshot is expensive, one lookup can take seconds, and in a suite that adds up fast. It's fragile because a path like the third child of the second layout depends on structure, and structure changes with screen size, OS version and small design tweaks. The alternatives are strategies the platform resolves natively: accessibility id, resource-id on Android, a UiSelector when I need text or other attributes, and on iOS a predicate string or class chain. If I really need XPath, I keep it short and anchored on a stable attribute, never on indexes."

"My main tool is Appium Inspector. I start the Appium server, give Inspector the same capabilities my test uses, and it opens a session showing a screenshot next to the element tree. I click an element and see its attributes: resource-id, content-desc, text and class on Android, or name, label, value and type on iOS. It suggests locators, and I can try a locator right there to see if it matches exactly one element before I put it in code. From the test itself, I can call getPageSource to dump the same XML, which I attach to failure reports. For the web part of a hybrid app, the native tree isn't enough, so I use Chrome's remote inspect page for an Android webview or Safari's Web Inspector for an iOS one, and pick CSS selectors there."

"Compose doesn't build classic Android views, so the resource-ids we relied on aren't there by default. Developers can give elements a test tag, but UiAutomator only sees test tags as resource-ids when the app switches on a semantics flag called testTagsAsResourceId, usually once near the root of the screen. So I ask for two things: turn that flag on, and add test tags to the elements we automate. I'd avoid asking them to put IDs into content descriptions, because TalkBack reads those aloud to real users. On SwiftUI the answer is the accessibility identifier modifier. It becomes the element's name, which Appium's accessibility id strategy matches, and VoiceOver doesn't read it. Best of all, I agree a naming convention with both teams, like login_button on each platform, so one accessibility id locator works on Android and iOS."

"Both are iOS-only strategies that XCTest evaluates natively, which is why they're so much faster than XPath. A predicate string matches elements by their attributes, like type, name, label or value, with conditions such as equals, contains or begins with, and I can join conditions with AND or OR. I use it when an element is best described by what it is, like a button whose label starts with Pay. A class chain describes a path through the hierarchy, like a light XPath: find a cell whose label contains Order, then the first button inside it. I use that when I need structure, for example a button inside a particular cell in a list. The filter in backticks inside a class chain is itself a predicate, so the two work together. One detail worth knowing: class chain indexes start at 1, not 0."

"TouchAction and MultiTouchAction were deprecated and then removed, so I use W3C Actions. I create a pointer input of kind touch and build a sequence: move to the start point, press down, move to the end point over a duration, then lift. The duration matters: a fast move is a fling, a slow one is a drag, and too short can be ignored by the app. Then I call perform. I calculate the start and end points from the screen or element size, like from four fifths of the way down to one fifth, so it works on any device. The other option is the driver's own commands through executeScript. The Android driver has mobile: swipeGesture and scrollGesture, and the iOS driver has mobile: swipe and scroll. Those are shorter and often more reliable, but they're platform-specific, so my helper picks one per platform."

"On Android, lists recycle their rows, so an item far down the list often isn't in the element tree at all until it's close to the screen. The cleanest fix is UiScrollable through the UiAutomator locator: I describe the scrollable container and the target, and UiAutomator scrolls on the device until it finds it, all in one call. On iOS, the XCUITest driver has a mobile: scroll command that can scroll a container in a direction, or toward a child element matched by name or predicate. When neither fits, for example a custom scroll view, I write a small helper: swipe, look for the element, and repeat, but stop after a set number of tries or when the page source stops changing, so it can't loop forever at the bottom of the list."

"First I confirm that's really the problem: the driver can tell me whether the keyboard is shown, and a screenshot at failure usually makes it obvious. Then I dismiss it in a way that matches what a user does. hideKeyboard works well on Android. On iOS it depends on which keys the keyboard has, so often the most reliable way is tapping the keyboard's Done or Return key, or tapping a neutral area of the screen. If the design keeps the keyboard open, I scroll the form so the button is visible instead. I put this in the page object's typing helper so every test gets it for free. And if a real user can't reach the button without closing the keyboard on small screens, that's worth raising as a usability bug too."

"A hybrid app exposes more than one context. NATIVE_APP is the normal one, and each inspectable web view shows up as a context whose name starts with WEBVIEW. When I get to the web screen, I first wait until the webview context appears, because it only shows once the page has loaded. Then I switch to it. From that point Appium sends my commands to a web automation backend, chromedriver on Android or the WebKit remote debugger on iOS, so I use CSS selectors like on a website. When the flow goes back to a native screen, or a native dialog pops up, I switch back to NATIVE_APP. I keep the switching inside the page objects, so tests never need to know which part of the screen is web and which is native."

"I'd check a few things in order. First, is the web view inspectable at all? On Android, the app has to turn on web contents debugging, usually only in debug or test builds, so a release build shows nothing. On recent iOS versions the app also has to mark its web view as inspectable, and on a real device Web Inspector needs to be enabled in Safari's settings. Second, is it really a web view? Many apps open pages in a Chrome custom tab, which is the Chrome app on top of yours, not your app's web view. Third, timing: the context only appears after the page loads, so I poll for it. And if the context is listed but switching fails, on Android that's usually a chromedriver that doesn't match the web view's Chrome version, which I fix by pointing Appium at the right one."

"Emulators and simulators are my first line. They start clean, run in parallel on CI machines, and are perfect for functional checks on every pull request. But they aren't real phones. Performance is different, hardware like the camera or real biometrics is faked or missing, and they don't show the changes phone makers add to Android, like aggressive battery savers that kill background apps. So before release I run on real devices, especially the lowest-end phone we support. A cloud farm gives me breadth, dozens of models and OS versions I don't own, but sessions are slower, there can be queues, and security has to approve sending test data there. I choose the device list from analytics: the most used OS versions and makers among our users, plus the smallest screen and the weakest device."

"Each session needs its own device, so I pass a unique udid, never just a device name. Then the ports. On Android, UiAutomator2 forwards a local port to its helper on the device, the systemPort, so each session needs a different one or they fight over it. If the tests touch webviews, the chromedriver port must differ too. On iOS the same idea applies to wdaLocalPort. I can run one Appium server with several sessions, or one server per device, which isolates logs nicely. On the test side, the driver lives in a ThreadLocal so parallel threads never share one, and my runner hands each thread a device from a pool. Finally the data: if four devices log in with the same account and change the same cart, tests fail for reasons that have nothing to do with the app, so each device gets its own account."

"I'd split it into layers. Tests describe the user flow and never touch the driver. Below them are screen objects, one per screen, exposing actions like logIn. Below that is a gesture and wait helper layer, and at the bottom a driver factory that reads config, platform, device and capabilities, and builds the right driver. For locators, the Java client lets me annotate each field with an Android locator and an iOS locator, so one screen class serves both. Where a screen behaves differently, for example a date picker, I use an interface with an Android and an iOS implementation. The biggest win is agreeing with developers on matching accessibility ids across both apps, so most fields have the same locator. Test data comes from APIs, and reports record platform, device and app build so a failure is easy to place."

"There's simply more between my code and the screen. First, device noise: animations, system pop-ups like OS updates or low battery, the keyboard covering elements, and state left over from the last test. I turn animations off on test devices, pre-grant permissions and reset app state on purpose. Second, timing: screens load data asynchronously, and emulators on busy CI machines are slow, so I use explicit waits on the condition I need, never fixed sleeps, and give emulators hardware acceleration. Third, infrastructure: the UiAutomator2 helper or WebDriverAgent can crash, devices disconnect, and parallel devices can share an account. Those show up as session errors, not assertion failures, so I track them separately. The method matters most: I tag every failure by cause from the logs and recordings, fix the biggest bucket first, and quarantine a test with a ticket rather than letting it cry wolf."

"At the moment of failure I capture a screenshot and the page source, so I can see both what the user saw and what the element tree looked like. I also record the screen for each test and keep the recording only if it fails; a video shows things a single screenshot misses, like a pop-up that came and went. Then logs: logcat on Android or the system log on iOS, which is where crashes and stack traces show up, and the Appium server log for that session, which shows exactly which command failed and why. Last, the context: device model, OS version, app build number and the capabilities used. All of it is attached to the test in the report. With that, most failures can be classified in a couple of minutes without rerunning anything."

"At my last company, our checkout test passed on every emulator and most phones, but failed on our smallest real device every time. The log said the Place order tap had no effect. I compared recordings from a passing and a failing device, and on the small screen the button sat just below the fold when the address form was open, so our tap hit the wrong spot. The test fix was easy: scroll the element into view before tapping, inside the page object. But I also checked it as a user, and on that phone you genuinely couldn't see the button without closing the keyboard first, which many people wouldn't think to do. I raised that as a real bug, and the design was changed. Afterwards we added the smallest supported screen to the pull request device set."

"In my last role I inherited an Appium suite that people ignored. It was mostly long XPaths with fixed sleeps, every test logged in through the UI, and a red run meant nothing because half of it failed at random. I started by tagging a month of failures by cause, which showed most were locators and timing. I agreed accessibility ids with both app teams and replaced the worst XPaths first, swapped sleeps for explicit waits, and moved login and test data setup to backend APIs. I also split a fast smoke set for pull requests from the full nightly run, and quarantined unstable tests with a ticket and an owner. After a couple of months a red run nearly always meant a real problem, and the proof was that developers started opening the reports themselves instead of asking me whether it was the tests again."

"In a previous project our nightly Appium run installed the app fresh on an emulator with the oldest Android version we still supported. One morning every test on that emulator failed at launch. The logcat we attach to failures showed a crash on start-up: a new feature called an Android API that doesn't exist on older versions, without checking the version first. Nobody had caught it by hand because the whole team used recent phones, and our manual checks upgraded an existing install rather than doing a fresh one. The developer added the version check the same day, before release. It changed two things for us. We kept the oldest supported OS in the nightly device list for good, and we added a fresh-install launch check to the pull request pipeline, since it takes under a minute."

"I wouldn't block on it, but I'd be careful how I build. For now I'd use the most stable thing each screen offers: a resource-id where one exists, content descriptions that are already there, short native queries on stable attributes, and XPath only anchored on something that won't move, never on indexes. Every locator lives in a screen object, so when ids arrive later I change one line, not fifty tests. I'd mark the weak locators in the code so the risk is visible. Then I'd make the request easy to say yes to: a short list of the exact elements on the screens our tests hit most, with suggested names that work for Android and iOS, ready to be done in the sprint after release. Adding an identifier is a tiny change per element, and showing a list of fifteen is much easier to agree to than asking for all of them."

"I'd start from data, not a wish list. Analytics tell me which OS versions, phone makers and screen sizes our users actually have, so I'd cover the ones that make up most of our users, then add the risky edges: the oldest OS we support, the smallest screen and the weakest device. That might be six or seven phones. The full regression suite runs on emulators and simulators, which are free to parallelise. On the real devices I run the smoke set and the flows that matter most for money and sign-in, where hardware and maker quirks bite. The rest of the twenty I rotate, a few per release, so over a month every one gets covered. And I'd write this down and share it, including what we're not testing on each release, so the risk is a team decision and not a surprise."

"First I'd accept the developers' behaviour as a signal: the suite isn't useful at ninety minutes. I'd pick a pull request set that finishes in about ten, covering sign-in, the main purchase flow and whatever the changed area touches, and move the rest to nightly and pre-release runs. Then I'd make each test cheaper. Most mobile time goes on setup, so I'd log in and create data through APIs, jump straight to screens with deep links, and stop reinstalling the app for every test. I'd remove fixed sleeps and slow XPath locators, which quietly add minutes. Then parallelise: several emulators with their own ports, tests sharded by their measured duration, and prebuilt helpers so sessions start quickly. Finally I'd delete or merge tests that have never caught anything. I'd share before and after timings so the team sees it's worth waiting for again."