In Appium, what does a default reset do to the app on Android, and what on iOS?
answer
- both flags false is still a strategy
- one platform clears, the other reinstalls
- package-manager data clear on Android
- iOS clean state rides on the install
basics
~20 sWith appium:noReset and appium:fullReset both false, the Android drivers clear the app's data in place and leave it installed, while the iOS driver has no in-place clear and gets a clean start only by reinstalling the app.
solid answer
~40 sA default session is one where `appium:noReset` and `appium:fullReset` are both left at `false`, and the driver is then expected to hand the test a fresh-install state. The mechanism differs by platform. On Android the drivers clear the app's data through the package manager: the binary stays installed and its data directory is emptied, which is quick and behaves the same on an emulator and on a phone. The XCUITest driver has no in-place clear on a device, so on iOS that same promise is delivered by **reinstalling the app** — which makes the guarantee only as strong as the install. If the session names an already-installed bundle and supplies no build, there is nothing to reinstall and nothing gets cleared. `mobile: clearApp` does empty an iOS app's container, but only on a simulator.
go deeper
Know that leaving both reset capabilities alone is itself a choice, and that it is meant to give you an app in fresh-install state. Do not yet worry about how each platform delivers that.
Be able to name both mechanisms and say which platform uses which: a package-manager data clear on Android, a reinstall on Apple platforms, plus the simulator-only in-place clear.
Demonstrate that you check whether the iOS lane actually supplies a build, because without one the default reset is a no-op and the suite has been running dirty without failing.
Frame the divergence as a design constraint on the whole suite: a guarantee that is cheap on one platform and conditional on the other cannot be expressed as one shared configuration value.
## What a default reset is A default Appium session is one where you set neither reset capability: `appium:noReset` and `appium:fullReset` are both left at their `false` default. The contract the driver tries to honour is the same everywhere — hand the test an app in the state a fresh install would leave it in — and the machinery behind that contract is completely different on the two platforms. Learning the contract without the machinery is exactly what produces a suite that is genuinely isolated on Android and quietly is not on iOS. ## Android: cleared in place On Android the drivers reach for a package-manager operation that empties an installed application's data. The binary stays where it is; its data directory is emptied. That single fact carries several consequences worth being able to state: - It is **cheap** — a second or two, with no transfer of the build over USB or the network. - It works **identically on an emulator and on a physical phone**, because it is a platform operation rather than a tooling trick. - It is **scoped to one package**. Anything a different app stored, and anything the system stores about the device, is untouched. - It needs **no artifact**. A session can identify the app by its installed package and still get a clean start. So on the Android lane, `appium:noReset: false` is a strong promise, and it is the promise most people think they are buying when they leave the reset capabilities alone. ## Apple platforms: cleaned by reinstalling The XCUITest driver has no in-place data clear it can use on a device. What it has is install and uninstall, so a clean container is a **side effect of putting the build on again**: the installed copy goes and the app comes back with an empty container. That reframes the guarantee completely, because a reinstall needs something to install. The one in-place lever on Apple platforms is `mobile: clearApp`, which removes an app's data container — and it is **simulator-only**, so a real-device lane cannot fall back to it. That is the whole reason the clean-state promise that holds on Android does not hold on an iPhone. ## The two mechanisms side by side | | Android drivers | XCUITest on Apple platforms | |---|---|---| | how a default reset cleans | package-manager data clear, in place | reinstalling the app the session supplies | | app installed afterwards | yes, the same copy | yes, a freshly installed copy | | needs the build artifact | no | yes, or nothing happens | | works on real hardware | yes | yes, when the build is supplied | | in-place clear during a session | `mobile: clearApp` | `mobile: clearApp`, simulator-only | ## Why the difference is structural, not an oversight A driver can only expose what the platform gives it. Android exposes an operation that empties an installed app's data on demand; Apple's tooling gives the driver install, uninstall, and container deletion on a simulator. Appium did not choose to make the platforms differ here — it surfaced the difference behind one pair of capability names, which is what makes the pair so easy to misread. Every time you read `appium:noReset: false` in a config, translate it into the platform's own verb before you believe it: 1. On Android, translate it as *the app's data will be cleared*. 2. On an Apple simulator or device, translate it as *the app will be reinstalled if this session has a build to install*. 3. If step 2 has no build, translate it as *nothing will happen*. ## What to do with this in a ferry timetable suite Suppose the suite drives a ferry timetable app that stores a home port and a signed-in account. On Android you can leave both flags false and trust the clear. On iOS you have to make a decision the Android lane never forced on you: - **Ship the artifact with the session** so the reinstall really happens, and accept the per-session install cost on hardware. - **Or set `appium:noReset` true and own the clean-up in the suite**, signing out or resetting through the app itself, so the isolation is something your code does rather than something you assume. - **Either way, assert the starting state** in the first step of the case. A dirty start should fail immediately and loudly, not surface three screens later as a flake. The sentence to avoid in a review is *the reset did not work on iOS*. Nothing failed: the driver did exactly what its clean-up means on that platform, and the session simply never gave it anything to reinstall.
- Why does an iOS session that names only a bundle id often start dirty even with the default reset?Because the XCUITest driver's between-session clean-up is install-shaped. With no build to install there is nothing to reinstall, so no data is removed and the app opens on the previous run's state. On a simulator `mobile: clearApp` can empty the container as a fallback; on a real device it is unavailable, so the suite has to clear the state itself.
- Does Android's default reset touch anything outside the app under test?No. The clear is scoped to that one package's own data — its databases, preferences and caches. Device-level state such as system settings, the clipboard, or anything a different app wrote is untouched, so residue from a previous run can still reach your test even though the app itself started empty.
Android's default reset is emptying the flat and handing back the same keys; the Apple one is demolishing the flat and rebuilding an identical one — and if nobody turns up with the plans, nothing gets emptied at all.
saying these in an interview costs you the question
- Says the default reset reinstalls the app on Android
- Assumes iOS clears app data in place the way Android does
- Thinks a default reset wipes the whole simulator or device
- Believes mobile: clearApp works on Apple real devices
- Treats a bundle-id-only iOS session as freshly installed