With appium:autoAcceptAlerts on, an iOS alert takes the wrong button. Which XCUITest settings pin the choice?

## The symptom, in a real run The bus-ticketing suite is green on Android. On iOS, a step that should leave the rider on the seat picker leaves them back on the route-search screen instead. The session was created with `appium:autoAcceptAlerts` set, so no line of your test code touched the dialog — that is the entire point of the capability — and yet something pressed a button. It pressed the wrong one. Nothing errored. That is what makes this a senior-level trap rather than a beginner one: the run continues down whichever branch the wrong button opened, and the failure surfaces one or two steps later somewhere that looks unrelated to alerts. ## What the capability actually decides `appium:autoAcceptAlerts` is a **capability**. You send it once, in the `capabilities` map of `POST /session`, and from then on the XCUITest driver deals with system alerts as they appear rather than waiting for a `mobile: alert` call from your code. Handing over that work also hands over a decision — *which control on the dialog counts as accepting it*. On a plain two-button dialog the driver's default detection is normally what you meant. On a dialog with three options, or one whose affirmative choice is not in the position the default assumes, it can land somewhere else. The capability is a convenience, and the price of the convenience is that the choice is no longer written down in your repository. ## The settings that take the decision back XCUITest exposes the choice as **settings**, and the names are almost self-describing: - `acceptAlertButtonSelector` — names the button an accept action should press - `dismissAlertButtonSelector` — the mirror image, for a dismiss action - `autoClickAlertSelector` — a selector for an element to be clicked automatically on an alert - `respectSystemAlerts` — governs whether a system alert is accounted for when the driver decides which application is currently active Pin the first two and the driver stops choosing for you: the accept path presses what you named, the dismiss path presses what you named, and the decision now lives in configuration a reviewer can read. ## Settings are not capabilities, and the difference bites This is the part people get wrong under pressure, because `appium:autoAcceptAlerts` and `acceptAlertButtonSelector` sound like members of the same family and are not: 1. A **capability** is negotiated once, in the body of `POST /session`, and carries the `appium:` vendor prefix when it is not one of the W3C standard names. 2. A **setting** is per-session state. You can seed settings at session creation through the `appium:settings` capability, and change them while the session is running. 3. So the button selectors can be adjusted mid-session for one screen and restored afterwards, while the auto-accept behaviour itself is fixed for the life of the session. That also means a suite can turn the selectors into a per-screen concern rather than a global one, which is usually what you want when only one dialog in the flow is ambiguous. ## How to diagnose it 1. Confirm the capability is actually on for that session. A run that never had `appium:autoAcceptAlerts` set is failing for a different reason entirely. 2. Establish what the dialog really offers — how many buttons, and which of them is the one your flow needs. 3. Pin it with `acceptAlertButtonSelector` (or `dismissAlertButtonSelector` if the flow needs the negative path). 4. Re-run and verify the branch taken, not just that the step passed. A wrong button often produces a passing step and a wrong screen. ## And on Android there is nothing equivalent The whole discussion above is iOS's. The Android drivers declare no alert-button selector, and no `appium:autoAcceptAlerts`. On Android with UiAutomator2 you have exactly two moves: - `mobile: acceptAlert` — take the affirmative action - `mobile: dismissAlert` — take the negative action You choose *when* to call them; you do not choose *which control* either one presses. That asymmetry is worth stating out loud in a review, because a shared configuration block that carries `acceptAlertButtonSelector` for both platforms is not doing half a job on Android — it is doing nothing at all there, silently. ## The takeaway Automatic handling is a trade, not a free win. On iOS you may take the convenience and then buy back the precision with the selector settings. On Android the trade is not on offer: the handling is explicit by construction, and the button is the driver's to choose.