Your Appium wine-cellar suite crawls on iOS and taps mid-animation on Android — what do you tune?

## Read the symptom as two faults, not one A suite that is slow on iOS and jumpy on Android looks like one inconsistency, and the instinct is to reach for a single number that will "balance" the two. That instinct is exactly wrong here, because Appium's pre-interaction idle check is two different mechanisms that happen to share a word. On Android the UiAutomator2 driver waits for the device's accessibility event stream to fall silent, bounded by its `waitForIdleTimeout` **setting** (10000 ms by default). On iOS the XCUITest driver waits for the app under test to become **quiescent** — for its main thread to stop working — bounded by `appium:waitForIdleTimeout`, with the `animationCoolOffTimeout` setting adding a further settle window afterwards. One value cannot be right for both, and a single shared constant in the framework config is usually the actual root cause of the report. ## The iOS half: an app that never goes quiet Slow-everywhere on iOS is the fingerprint of a main thread that never settles. Because the signal is the app's own run loop rather than the element you are touching, the offender does not need to be on screen near the tap: - an activity spinner left running while the wine-cellar app re-syncs its bottle list - an animation configured to repeat indefinitely, such as a shimmering placeholder on the cellar shelves - a timer redrawing a label — a countdown to the next stock take — every frame Each one means the driver waits out the whole bound before every single interaction, so the suite's runtime scales with the number of commands rather than with anything the app is actually doing. Confirm it before you tune it: time individual commands and look for a uniform per-command cost rather than a few slow spots. A uniform cost is quiescence; a few slow spots are something else. The honest fix order is: 1. **Fix the app** where the endless animation is not a product requirement. A shimmer that stops when data arrives costs nothing and returns the driver's fast path. 2. **Lower `appium:waitForIdleTimeout`** where the animation is a requirement. This caps how long the driver blocks on a thread that will never go quiet — and you are explicitly buying speed by letting the driver act before the app has settled. 3. **Set `animationCoolOffTimeout` deliberately** rather than leaving it to chance, since it is the second stage that runs after quiescence is reported and it is paid on every interaction too. ## The Android half: an idle check that was switched off Taps landing mid-animation on Android is the mirror image, and it is nearly always self-inflicted. UiAutomator2's `waitForIdleTimeout` is a driver setting; someone who found the suite slow will have reduced it, or set it to `0`, which disables the wait entirely and lets interactions land immediately whether or not the screen has stopped moving. What to check and adjust on that side: - Whether `appium:settings[waitForIdleTimeout]` is being sent at session start, or the value is being changed mid-session through the driver's settings API. - Whether the value is `0`. Restoring a bounded value — the 10000 ms default, or a smaller but non-zero ceiling — buys the wait back without reinstating the worst case. - UiAutomator2's neighbouring acknowledgment settings, `actionAcknowledgmentTimeout` (3000 ms) and `scrollAcknowledgmentTimeout` (200 ms), which bound how long the driver waits for an action or a scroll to be acknowledged. They are separate from idle detection and are a second reason an Android interaction can appear to return before the screen has caught up. ## The comparison that drives the decision | | Android — UiAutomator2 driver | iOS — XCUITest driver | |---|---|---| | Typical failure mode here | wait disabled, taps land early | wait always exhausted, suite crawls | | Knob | `waitForIdleTimeout` setting | `appium:waitForIdleTimeout` | | Signal it bounds | accessibility event stream | app main thread quiescence | | Second knob in play | acknowledgment timeouts | `animationCoolOffTimeout` | | Direction of the fix | raise back to a bounded value | remove the noise, then cap | ## What you are actually trading Every choice here is the same trade in two directions: **time spent waiting versus the chance of acting on a screen that has not settled**. Lowering a bound never makes an app settle faster; it only makes the driver stop caring sooner. So the defensible order is to remove the thing that keeps the app busy first, and to reach for the timeout only when the busyness is a product decision you cannot change. The framework-level lesson is the one to say out loud in an interview: idle configuration on Appium is per-platform by nature. A capability builder that applies one `IDLE_TIMEOUT` constant to both an Android and an Apple session has encoded a false equivalence, and every future tuning argument on that suite will be fought on the wrong ground.