Install and Removal

## Three commands, and the names are shared Appium exposes app installation as **driver execute methods** posted to a live session, rather than as a set of bespoke HTTP verbs you learn separately. Three of them cover putting a build on a target and taking it off again, and they carry the same names on Android and on Apple platforms: - `mobile: installApp` — put a build on the target. - `mobile: removeApp` — take an installed app off it. - `mobile: isAppInstalled` — report whether an app with a given identifier is present. The shared naming is genuinely convenient, and it is also the trap on this subject: the same name does not imply the same machinery, the same artifact, or the same argument. ## Where each name is actually declared On Android the three come from **`appium-android-driver`**, the base driver that the UiAutomator2 and the Espresso drivers both extend, so a session on either driver has them. On Apple platforms the **XCUITest driver** declares its own `mobile: installApp`, `mobile: removeApp` and `mobile: isAppInstalled` in its own execute-method map, alongside the rest of its app lifecycle surface and `mobile: listApps`. Two habits follow from that, and both are worth forming early: - Attribute a command to the right driver family. Saying *the UiAutomator2 driver's `mobile: installApp`* reads as true and is not, because the method comes from the shared Android base. - Never assume a command exists on the other platform because you found it on this one. UiAutomator2's `mobile: installMultipleApks`, for split builds, has no Apple counterpart at all. ## What you pass them is not the same To install, you supply an artifact, and the platforms accept different ones. To remove or to check, you supply the app's own identifier, and the platforms spell identity differently — a package name on Android, a bundle id on Apple platforms. | | Android | Apple platforms | |---|---|---| | declared by | `appium-android-driver`, inherited by UiAutomator2 and Espresso | the XCUITest driver's own execute-method map | | install artifact | `.apk`, or an `.apks` archive carrying a split set | `.ipa` archive, or an `.app` bundle | | multi-artifact install | UiAutomator2's `mobile: installMultipleApks` | none | | identity passed to remove or check | the package name | the bundle id | That table is the honest shape of the subject: one vocabulary, two mechanisms. Which capabilities name an artifact or an identity when the **session starts** is a separate subject; these three methods are what you call once a session is already running. ## The endpoints did not disappear Appium 3 moved a great deal of the old `/appium/...` surface into per-driver execute methods, and the app-management routes are a measured exception. `install_app`, `remove_app` and `app_installed` are still declared in the core route table, under `/session/:sessionId/appium/device/`. The `mobile:` execute methods are the richer, per-driver surface — more options and driver-specific behaviour — but a client that still calls those routes is not calling something that was deleted. Note the spelling too: the source writes `:sessionId`, never `:id`. ## Using them without lying to yourself - Make setup **idempotent**: check with `mobile: isAppInstalled`, remove with `mobile: removeApp` if you need a clean slate, then install. A step that assumes a virgin device fails on the second run of the day. - Remember what the check proves. `mobile: isAppInstalled` answers whether that identifier is present — not whether the build behind it is the one your pipeline just produced. - Keep install out of the assertion path. It belongs in setup, where a failure reads as a setup failure rather than as a broken hive-log feature. - Expect install to cost real time on hardware, and to cost more the larger the artifact. It is the first thing a mobile suite does and the most common place a suite appears to stall. - Log which artifact path went to which target. When two lanes disagree, that line answers the question faster than any screenshot. For a beekeeping hive-log suite this means one small, boring setup helper: is the app there, do we want it gone, put the right artifact on, and record what we did. Everything platform-specific about it lives in the artifact and the identifier, not in the command names.