Your Appium ferry timetable suite starts every iOS real-device session already signed in, though appium:noReset is false. Why?

## What the capability actually promises The first correction to make is to the mental model, not the config. `appium:noReset: false` does not say *clear this app's data*. It says *you may do your normal between-session clean-up*, and it is each driver that decides what that clean-up is. On Android the drivers clear the app's data in place through the package manager, and the promise is unconditional: any installed package can be emptied. On Apple platforms the XCUITest driver has no in-place clear it can use on a device, so its clean-up is **install-shaped** — the app is reinstalled, and the old container goes with the old copy. An install-shaped clean-up has a precondition that a data clear does not: **there has to be something to install**. A session that identifies the ferry timetable app by an already-installed bundle and supplies no artifact gives the driver nothing to do. No error is raised, because nothing went wrong; the driver simply had no clean-up to perform. Your suite then opens the app on the previous run's data, including whatever kept it signed in. ## Why the Apple lane is the one that breaks The simulator lane usually hides this, which is why the bug reaches hardware. On a simulator a suite often does install the build every session, and `mobile: clearApp` is available as a fallback that empties the app's data container. On a real device neither holds: - `mobile: clearApp` is **simulator-only**, so calling it on hardware fails the case rather than cleaning it. - Without an artifact, no reinstall happens, so the default reset is a no-op. - Nothing in the run turns red, so the suite has been running dirty for as long as anyone cares to look back. Meanwhile the Android lane is genuinely clean on the same configuration, which is exactly what makes the report so convincing and so misleading. A green cross-platform run does not mean both lanes were isolated. ## Reading the run instead of guessing Prove the mechanism rather than arguing about it: 1. **Write a marker, then look for it.** In one session store an obvious value in the app; start a second session with the same capabilities and read it back. If it is there, nothing was cleared. 2. **Read the server log around session start.** Look for whether the driver installed anything at all. A session that never installed cannot have reset anything. 3. **Check what the capabilities actually identify.** A session pointed at an installed bundle with no build is the classic shape of this defect. 4. **Run the same case on a simulator.** If it is clean there and dirty on hardware, you have confirmed the divergence rather than a bug in the app. ## The three fixes and what each costs | fix | what it buys | what it costs | |---|---|---| | ship the build with every session | the reinstall really happens, so the container is genuinely fresh | an install per session on real hardware, plus getting the artifact to the run | | set `appium:fullReset` | the app is removed before the session, the strongest guarantee there is | the same install cost plus the removal, on every single session | | let the suite reset state itself | works identically on both platforms and on hardware | you must build and maintain a sign-out or reset path, and prove it ran | The third is the one senior suites usually land on, because it is the only option whose behaviour does not change when the lane changes. It also has a trap of its own: swapping a silent driver assumption for a silent suite assumption gains nothing. Whatever the reset path is, the case must **assert** the state it expects before it starts, so a dirty start fails at the first step with an obvious message instead of surfacing three screens later as a flake. ## What this should change about the Android result The useful takeaway is not *iOS is broken*. It is that the reset capabilities express intent while each platform supplies a mechanism, so a value that means *cleared* on one lane can mean *untouched* on another. Two habits follow: - Never generalise a clean simulator lane to a real-device lane; the available mechanisms are not the same. - Never treat a capability as a guarantee you have not observed at least once on the hardware you actually run. And resist two tempting non-fixes. Raising a timeout does nothing, because nothing is slow — nothing is happening at all. Blaming the app for caching too aggressively is equally wide of the mark: the app is behaving correctly for an install that was never replaced.