In Appium, what actually happens when mobile: installApp runs on Android versus iOS?

## The same method name, two different machines `mobile: installApp` is declared twice in the Appium ecosystem: once by `appium-android-driver`, the base driver that the UiAutomator2 and Espresso drivers extend, and once by the XCUITest driver in its own execute-method map. A test calls the same name in both lanes. Underneath, almost nothing is shared — not the transport, not the tool that performs the install, and not what the platform requires of the file. Knowing which machine runs is the difference between guessing at an install failure and reading it. ## Android: the drivers work through their adb layer On Android the driver does not install anything itself. It delegates to **`appium-adb`**, the package that wraps the Android debug bridge for the driver's own use, and that layer does the transfer and drives the platform package installer on the device. A few consequences follow that are worth holding on to: - The artifact is a single `.apk`, or an `.apks` archive carrying a split set. When the build arrives as loose splits, UiAutomator2's own `mobile: installMultipleApks` is what installs them as one transaction. - `appium-adb` carries a **bundled default certificate**, and the UiAutomator2 driver will **re-sign the app under test** when a certificate check fails — so the build that ends up on the device is not always byte-identical to the one your pipeline produced. - Install time scales with artifact size and device speed, and it is a real cost on hardware. It is the most common place a mobile suite appears to hang at startup. - Because the whole path is host-driven, an install failure usually surfaces as a driver-side error carrying the package installer's own message behind it. How you use adb directly, and how a release build is signed for distribution, are separate subjects. What matters here is that the Android install path is one route whatever the target: an emulator and a phone are reached the same way. ## Apple platforms: one method, two routes The XCUITest driver's target set is wider than the word iOS suggests — it covers iOS and iPadOS on simulators and real devices, tvOS on both, and watchOS on simulators. What matters for install is the **target kind**: - For a **simulator**, the driver works through `simctl`, the command-line control surface for Apple simulators. - For a **real device**, it works through `devicectl`, and newer real devices are reached over an optional remote-XPC tunnel package that the driver declares as an optional dependency. So one execute method fans out to two mechanisms, and they do not fail in the same way. A simulator install is fast, local and forgiving. A device install goes over a connection that must be established first, and it accepts only an artifact built for hardware — a `.app` bundle produced for the Simulator is not what a device takes. | | Android | Apple platforms | |---|---|---| | declared by | `appium-android-driver` | the XCUITest driver | | does the work | `appium-adb` and the device package installer | `simctl` for simulators, `devicectl` for real devices | | artifact | `.apk`, `.apks`, or splits via `mobile: installMultipleApks` | `.ipa` archive or `.app` bundle | | may alter the artifact | yes — re-signing when a certificate check fails | no | | same route for virtual and physical | yes | no — two different tools | ## Why this shows up as a timing and reliability difference Work through a beekeeping hive-log suite that installs before each session: 1. On an Android emulator, install is a local transfer and completes quickly. 2. On an Android phone, the same call takes noticeably longer, in proportion to the artifact. 3. On an Apple simulator, install is close to instant, because `simctl` is placing a bundle on the same machine. 4. On a real Apple device, the driver must reach the device at all before it can install, so the failure modes include connection problems that have nothing to do with your build. That asymmetry is why a suite that is stable on simulators and emulators can turn slow and flaky the day it moves to hardware, without a single test changing. ## What to take away - The command name is shared; the mechanism is not, and you should be able to name the tool each platform uses. - On Android, expect a host-driven install through the driver's adb layer, and be aware the driver may re-sign the app under test. - On Apple platforms, expect the target kind to decide the route, and expect a device install to be the fragile one. - When an install fails, first say which of these machines was running. The answer usually names the fix.