In Appium, what does mobile: clearApp do on Android, and what does it do on iOS?

middlemust knowfreq 66%

answer

same command name, two mechanisms
one platform wipes data in place
the other deletes a data container
Simulator-only on the Apple side

basics

~20 s

Appium's mobile: clearApp wipes an installed app's stored data without reinstalling it. On Android the driver runs a package-data clear (pm clear) on the package; on iOS the XCUITest driver deletes the app's data container, and only on a Simulator.

solid answer

~40 s

mobile: clearApp is one execute-method name with two different implementations. On Android it is declared by appium-android-driver, which the UiAutomator2 driver and the Espresso driver both extend, and it performs a package-data clear (pm clear) against the package: databases, preferences and caches go, the APK stays installed, and it runs on an emulator or a real device. On Apple platforms the XCUITest driver instead deletes the app's data container, and that path is Simulator-only — against a real device it throws. You post it to POST /session/:sessionId/execute/sync with the app identifier, the package name on Android and the bundle id on iOS. Treat the app as no longer in the foreground once the call returns, and remember that iOS keychain entries live outside the container.

`mobile: clearApp` is one execute-method name with two different implementations. On **Android** it is declared by `appium-android-driver`, which the UiAutomator2 driver and the Espresso driver both extend, and it performs a package-data clear (`pm clear`) against the package: databases, preferences and caches go, the APK stays installed, and it runs on an emulator or a real device. On **Apple platforms** the XCUITest driver instead deletes the app's data container, and that path is **Simulator-only** — against a real device it throws. You post it to `POST /session/:sessionId/execute/sync` with the app identifier, the package name on Android and the bundle id on iOS. Treat the app as no longer in the foreground once the call returns, and remember that iOS keychain entries live outside the container.

code

python · 13 lines

python

MUSEUM_ANDROID_PACKAGE = 'org.museum.audioguide'
MUSEUM_IOS_BUNDLE_ID = 'org.museum.audioguide'


def clear_audio_guide(driver):
    platform = str(driver.capabilities.get('platformName', '')).lower()
    if platform == 'android':
        # Android drivers: package-data clear, emulator or real device
        driver.execute_script('mobile: clearApp', {'appId': MUSEUM_ANDROID_PACKAGE})
    else:
        # XCUITest: deletes the data container, Simulator only
        driver.execute_script('mobile: clearApp', {'bundleId': MUSEUM_IOS_BUNDLE_ID})
        driver.execute_script('mobile: clearKeychains', {})

go deeper

for a junior

Know that Appium can empty an app's stored data mid-session with mobile: clearApp, and that the app itself stays installed afterwards.

for a middle

Be ready to explain both mechanisms: a package-data clear on Android against a data-container delete on iOS, and to say which of the two is Simulator-only.

for a senior

Be able to say what a case must do after the call, since the app is no longer in the foreground, and how the Apple restriction shapes which tier runs which cases.

for a principal

Own the trade-off between clearing in place and reinstalling per case, and decide where an Apple real-device tier fits when in-place clearing is not available there.

Why a mid-session wipe exists

A suite for a museum audio-guide app has cases that only make sense on a blank install: the first-run language picker, the empty-bookmarks screen, the prompt that offers to download the Renaissance-wing tour. Once one case has downloaded that tour and bookmarked three exhibits, the next case meets a returning visitor instead of a new one. Reinstalling the build between cases is the obvious fix and the slowest one. mobile: clearApp is Appium's alternative: it empties the app's stored data in place, inside a live session, and leaves the binary installed.

It is an execute method, not an endpoint of its own. The client posts it to POST /session/:sessionId/execute/sync with the mobile: name in script and a single parameter map carrying the app identifier. Appium 3 removed the old POST /session/:sessionId/appium/app/reset route and named mobile: clearApp as its replacement, so this is where app-data wiping now lives on both platforms.

Android: a package-data clear

On Android the method is declared by appium-android-driver, the base driver that both the UiAutomator2 driver and the Espresso driver extend, so it is available whichever of those two you drive with. Its mechanism is a package-data clear — the pm clear operation against the package you name:

Everything in the package's private data directory goes: databases, shared preferences, cached tour audio, files the app wrote.
The APK stays installed; you have not lost the build or its signature.
It runs the same way on an emulator and on a real device — there is no virtual-only restriction on this side.
The package's process is stopped, so the app is not in the foreground when the call returns.
Runtime permission grants go with the rest of the package state; re-granting them is the permissions subject, not this one.

The identifier it takes is the package name — the same value you would name in appium:appPackage.

Apple platforms: a data-container delete

The XCUITest driver declares mobile: clearApp too, and the name is the only thing the two share. Its mechanism is a delete of the app's data container, and it carries a restriction Android's does not:

It is Simulator-only. Appium's own migration table footnotes the replacement as supported on emulators and simulators, and on the Apple side that is the whole story: against a real device the call throws.
A Simulator's app container is a directory the driver can reach and remove; a real device's sandbox is not addressable that way, which is why the restriction lands here and not on Android.
The identifier it takes is the bundle id, the value you would see in appium:bundleId.
The keychain is not inside the data container, so a membership token the audio-guide app stored there survives the wipe. XCUITest ships mobile: clearKeychains for that store, and it is Simulator-only as well.

The two mechanisms side by side

	Android drivers	XCUITest driver
Mechanism	package-data clear (`pm clear`)	delete of the app data container
Identifier taken	package name	bundle id
Real devices	yes	no, it throws — Simulator only
Companion command	usually none needed	`mobile: clearKeychains`
App left installed	yes	yes

What this command is not

It is not session-start reset policy. appium:noReset and appium:fullReset decide what happens when a session is created; mobile: clearApp is something you call inside a session that is already running. Different mechanism, different subject.
It is not a reinstall. If you need a genuinely fresh install — a new build, a changed signature — that is the install-and-removal subject and a slower operation.
It is not test-data seeding. Wiping the device side says nothing about the visitor record on the museum's backend; arranging that lives elsewhere.
It is not a raw shell call. You are asking the driver to perform the clear through its own execute method rather than opening a shell yourself.

The practical shape to carry away: same command name, two mechanisms, one restriction. Call it, then bring the app back to the foreground before your first find, and on the Apple side only expect to have the tool at all when the target is a Simulator.

## Why a mid-session wipe exists A suite for a **museum audio-guide app** has cases that only make sense on a blank install: the first-run language picker, the empty-bookmarks screen, the prompt that offers to download the Renaissance-wing tour. Once one case has downloaded that tour and bookmarked three exhibits, the next case meets a returning visitor instead of a new one. Reinstalling the build between cases is the obvious fix and the slowest one. `mobile: clearApp` is Appium's alternative: it empties the app's stored data in place, inside a live session, and leaves the binary installed. It is an **execute method**, not an endpoint of its own. The client posts it to `POST /session/:sessionId/execute/sync` with the `mobile:` name in `script` and a single parameter map carrying the app identifier. Appium 3 removed the old `POST /session/:sessionId/appium/app/reset` route and named `mobile: clearApp` as its replacement, so this is where app-data wiping now lives on both platforms. ## Android: a package-data clear On Android the method is declared by `appium-android-driver`, the base driver that both the **UiAutomator2** driver and the **Espresso** driver extend, so it is available whichever of those two you drive with. Its mechanism is a package-data clear — the `pm clear` operation against the package you name: - Everything in the package's private data directory goes: databases, shared preferences, cached tour audio, files the app wrote. - The APK stays installed; you have not lost the build or its signature. - It runs the same way on an emulator and on a real device — there is no virtual-only restriction on this side. - The package's process is stopped, so the app is not in the foreground when the call returns. - Runtime permission grants go with the rest of the package state; re-granting them is the permissions subject, not this one. The identifier it takes is the package name — the same value you would name in `appium:appPackage`. ## Apple platforms: a data-container delete The XCUITest driver declares `mobile: clearApp` too, and the name is the only thing the two share. Its mechanism is a **delete of the app's data container**, and it carries a restriction Android's does not: - It is **Simulator-only**. Appium's own migration table footnotes the replacement as supported on emulators and simulators, and on the Apple side that is the whole story: against a real device the call throws. - A Simulator's app container is a directory the driver can reach and remove; a real device's sandbox is not addressable that way, which is why the restriction lands here and not on Android. - The identifier it takes is the bundle id, the value you would see in `appium:bundleId`. - The **keychain is not inside the data container**, so a membership token the audio-guide app stored there survives the wipe. XCUITest ships `mobile: clearKeychains` for that store, and it is Simulator-only as well. ## The two mechanisms side by side | | Android drivers | XCUITest driver | |---|---|---| | Mechanism | package-data clear (`pm clear`) | delete of the app data container | | Identifier taken | package name | bundle id | | Real devices | yes | no, it throws — Simulator only | | Companion command | usually none needed | `mobile: clearKeychains` | | App left installed | yes | yes | ## What this command is not 1. It is not session-start reset policy. `appium:noReset` and `appium:fullReset` decide what happens when a session is created; `mobile: clearApp` is something you call inside a session that is already running. Different mechanism, different subject. 2. It is not a reinstall. If you need a genuinely fresh install — a new build, a changed signature — that is the install-and-removal subject and a slower operation. 3. It is not test-data seeding. Wiping the device side says nothing about the visitor record on the museum's backend; arranging that lives elsewhere. 4. It is not a raw shell call. You are asking the driver to perform the clear through its own execute method rather than opening a shell yourself. The practical shape to carry away: same command name, two mechanisms, one restriction. Call it, then bring the app back to the foreground before your first find, and on the Apple side only expect to have the tool at all when the target is a Simulator.

Which driver declares mobile: clearApp for Android, and does the Espresso driver have it too?
It is declared by `appium-android-driver`, the base driver. The UiAutomator2 driver and the Espresso driver both extend that base, so both inherit it — this is not a UiAutomator2-only command. The UiAutomator2 driver's own execute-method map holds its gesture and window commands, not the app-management ones.
What replaced the old POST /session/:sessionId/appium/app/reset route?
Appium 3 removed it and pushed the work into per-driver execute methods, with `mobile: clearApp` as the named replacement. Do not generalise from that: the install, remove, activate, terminate and app-state routes survived the cull, so check a route table before claiming any particular endpoint is gone.

saying these in an interview costs you the question

Says mobile: clearApp reinstalls the app on both platforms
Assumes the iOS clear works against a real device
Treats it as the same thing as appium:fullReset at session start
Believes both platforms share one implementation of the command
Expects the app to still be in the foreground after the call

In Appium, what does mobile: clearApp do on Android, and what does it do on iOS?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Why a mid-session wipe exists

Android: a package-data clear

Apple platforms: a data-container delete

The two mechanisms side by side

What this command is not

▾common follow-ups2 questions

▾red flags5 flags

Why a mid-session wipe exists

Android: a package-data clear

Apple platforms: a data-container delete

The two mechanisms side by side

What this command is not

answer

go deeper