skip to content

Appium's mobile: clearApp clears state on Android but throws on Apple real devices — how should a suite handle that gap?

level: principalimportance: should knowfreq 36%

answer

  1. one tier cannot wipe at all
  2. route the cases, do not catch
  3. Simulator has it, real device does not
  4. a skipped wipe means order dependence

basics

~20 s

Make the gap explicit rather than hiding it. Keep the in-place clear on Android and on Apple Simulators, let the helper fail loudly on an Apple real device, and decide per tier which cases are allowed to run there.

solid answer

~40 s

Treat it as a **tier decision**, not a coding problem. On Android `mobile: clearApp` is a package-data clear that runs anywhere; on Apple platforms it is a data-container delete that only a Simulator will run, and `mobile: clearKeychains` shares that restriction. So route the cases that genuinely need a blank slate at the Android tier and an Apple **Simulator** tier, and give the Apple real-device tier the cases that need real hardware and can start from carried-over state. Whatever you choose, do not let a cross-platform helper catch the real-device failure and continue: a silently skipped wipe becomes an order-dependent suite that passes today and fails when the shard order moves. If a real device truly needs a clean start, pay for a heavier reset knowingly and record it in that tier's configuration.

code

python · 12 lines
python
AUDIO_GUIDE_ID = 'org.museum.audioguide'


def clear_between_cases(driver, tier):
    if tier == 'android':
        driver.execute_script('mobile: clearApp', {'appId': AUDIO_GUIDE_ID})
        return
    if tier == 'ios-simulator':
        driver.execute_script('mobile: clearApp', {'bundleId': AUDIO_GUIDE_ID})
        driver.execute_script('mobile: clearKeychains', {})
        return
    raise RuntimeError('no in-place wipe on an Apple real device: route this case elsewhere')

go deeper

for a junior

Know that the in-place wipe is not available on every target, so a case that assumes a blank slate cannot simply run everywhere.

for a middle

Be ready to name the restriction precisely: the Apple container delete and keychain clear are Simulator-only, while the Android package-data clear is not.

for a senior

Explain how you route wipe-dependent cases by tier, and why a caught exception around the clear produces an order-dependent suite.

for a principal

Own the tier split itself: what the real-device tier exists to prove, what coverage it gives up without a per-case wipe, and how you keep that trade-off visible.

## The gap, stated precisely The command carries one name on both platforms and is not one capability: - **Android** — `mobile: clearApp` performs a package-data clear against the package. It runs on an emulator and on a real device alike. - **Apple platforms** — the XCUITest driver's `mobile: clearApp` deletes the app's data container, and that path is **Simulator-only**. Against a real device it throws. `mobile: clearKeychains`, the companion you need for credentials there, carries the same restriction. So a suite that wipes the **museum audio-guide app** between cases has a per-case reset on two of its three tiers and none on the third. That is a fact about the platform rather than a gap you can code around, and the interesting question is what the suite does about it. ## Three ways to close it, and what each costs 1. **Route by need.** Cases that require a blank slate — first-run onboarding, the empty-bookmarks screen, the initial download prompt — run on the Android tier and on an Apple Simulator tier where both wipe commands exist. The Apple real-device tier keeps the cases that genuinely need real hardware and tolerate a returning-visitor start. Cost: real-device coverage is deliberately narrower, and you have to keep explaining why. 2. **Pay for a heavier reset on that tier.** Getting a clean install on an Apple real device means going back through install-and-removal or through the session-start reset capabilities — slower mechanisms owned by other subjects. Cost: run time, plus a reset granularity that is usually per session rather than per case, which reshapes how cases are grouped. 3. **Make that tier order-independent by design.** Cases that arrange their own preconditions and assert relative to them need no wipe at all. Cost: this is case-design work rather than tooling work, it belongs to the mobile-test-design subject, and it is not free — but it is the only option that scales to a target where no in-place wipe exists. Most real suites run one and two together and drift toward three over time. ## Why swallowing the error is the worst option A cross-platform helper with a catch around the clear and a comment saying it is unsupported here is the tempting shortcut, and it produces exactly the failure mode you least want: - Cases keep running, so nothing goes red, so nobody makes a decision. - The tier quietly becomes order-dependent: it passes in the order it happens to run today and fails when a shard boundary moves. - When it finally fails, it looks like a product bug on real hardware — the most expensive red herring a mobile suite can produce. - The knowledge that this tier cannot wipe now lives inside a catch block instead of in the tier's configuration, where the next engineer would look for it. Let the helper raise, and name the platform in the message. A loud failure forces a design decision into the open; a caught one makes the same decision silently and badly. ## Making the decision visible | Tier | In-place wipe available | Suitable for | |---|---|---| | Android emulator or device | yes, a package-data clear | any case, including first-run | | Apple Simulator | yes, container delete plus keychain clear | any case, including first-run | | Apple real device | no, the call throws | cases that tolerate carried-over state | - Record each tier's wipe capability where the tier is configured, not inside a helper's error handling. - Give the cases that need a blank slate a marker of their own so routing them is mechanical rather than tribal knowledge. - Re-check the split whenever the reason for the real-device tier changes; a tier that exists for camera or biometric coverage may not need first-run cases at all. - Keep platform names in the messages the suite emits, so a failure says which side of the divergence it came from. ## What is not yours to decide here Which devices and OS versions the matrix covers, how cases are grouped into sessions, and what a case must assert after an interruption all belong to other subjects. What belongs to this one is narrow and worth being exact about: on Android the wipe is a package-data clear available everywhere, and on Apple platforms it is a container delete available on a Simulator only. A suite that pretends otherwise is lying to itself in the most expensive place it could choose.

  • Why not just catch the error on Apple real devices and carry on?
    Because the wipe silently stops happening. Cases then depend on the order they run in, pass today, and fail when a shard boundary moves — and the failure surfaces as an apparent product bug on real hardware. Raise instead, name the platform, and route the case where it can be cleared.
  • Does the keychain clear change the picture on an Apple real device?
    No. `mobile: clearKeychains` is Simulator-only, exactly like `mobile: clearApp` on that platform, so it closes nothing on real hardware. Treat credential-dependent first-run cases as Simulator cases and say so where the tier is configured.

saying these in an interview costs you the question

  • Wraps the failing call in a silent catch and moves on
  • Claims a real-device clear works with the right capability
  • Assumes an Apple real device can run the keychain clear
  • Treats a skipped wipe as harmless because cases still pass
  • Clears only on Android and hopes the Apple tier copes