skip to content

Your Appium iOS session mistypes a fishing-quota vessel name — which XCUITest settings do you check?

level: seniorimportance: must knowfreq 52%

answer

  1. classify the damage first
  2. missing versus changed characters
  3. the rate knob is iOS only
  4. the keyboard is editing you
  5. settings belong at session start

basics

~20 s

Classify the damage first. Missing characters point at maxTypingFrequency, the XCUITest setting bounding delivery rate. Substituted or completed words point at keyboardAutocorrection and keyboardPrediction, where the app's own keyboard rewrote the entry. Leftover text points at useClearTextShortcut.

solid answer

~40 s

On iOS the XCUITest driver types through WebDriverAgent into the keyboard the app is actually showing, so that keyboard's behaviour is part of your test. Read the field back and look at *how* it is wrong. Characters simply missing from an otherwise correct string is a delivery-rate problem — lower `maxTypingFrequency`. Words that are complete but different, or completed to something plausible, is the keyboard helping: turn off `keyboardAutocorrection` and `keyboardPrediction`. Text left over from a previous entry points at how the field was emptied, where `useClearTextShortcut` applies. Supply these through the session's settings, ideally at session start under the `appium:settings` capability so the configuration sits with the rest of the capabilities. None of these knobs exists on Android, so do not go looking for them there.

go deeper

for a junior

Know that on iOS the text goes through the app's own keyboard, so what the field holds afterwards is worth checking rather than assuming.

for a middle

Be able to name the XCUITest settings by job: maxTypingFrequency for rate, keyboardAutocorrection and keyboardPrediction for rewriting, useClearTextShortcut for emptying a field.

for a senior

Demonstrate the triage: read the value back, classify missing versus changed versus leftover, change one setting at a time, and confirm the Android lane is untouched before altering anything shared.

for a principal

Set the policy — a deterministic keyboard pinned in capabilities across the fleet, with assistive behaviour re-enabled only inside the cases that exist to test it.

## Two failure signatures, two different causes A fishing-quota logging app has exactly the fields that expose iOS typing problems: vessel names with accented characters, species names the keyboard thinks it knows better than you do, and decimal catch weights. When an iOS entry comes out wrong, the first move is not to reach for a setting — it is to read the field back and classify the damage. - **Characters are missing** from an otherwise correct string, usually more of them the longer the string. `Njordr II` where you sent `Njordur II`. This is a delivery problem. - **Characters are different.** The string is complete and plausible but not yours: a capital appeared, a word was completed, an accent turned into an ASCII neighbour. This is the keyboard editing you. - **The field holds more than you sent**, including remnants of an earlier value. This is an emptying problem, not a typing problem. Those three signatures have three different owners, and treating them as one bug is why this so often gets logged as flake and retried instead of fixed. ## The XCUITest settings that own each signature | Signature | Setting to reach for | What it governs | |---|---|---| | Characters missing | `maxTypingFrequency` | how fast characters are delivered while typing | | Characters changed or completed | `keyboardAutocorrection`, `keyboardPrediction` | whether the keyboard corrects and suggests as you type | | Old text still present | `useClearTextShortcut` | how the driver empties a field before entry | All three rows are XCUITest's. **The Android drivers expose none of them** — there is no typing-rate setting and no autocorrection switch on that side, because the Android agent does not put your string through the app's on-screen keyboard the same way. That asymmetry is the reason the same test can be reliably green on Android and reliably wrong on iOS, and a candidate who reaches for an Android capability to fix an iOS typing defect has misread the architecture. ## Where the settings are supplied Session settings can be applied mid-session, but for typing fidelity the better home is session start, supplied under the `appium:settings` capability keyed by setting name — the same shape as `appium:settings[maxTypingFrequency]`. Two reasons: 1. **It is configuration, not test logic.** A suite that disables keyboard autocorrection does so for every case, not only for the one that noticed. 2. **It is greppable.** A setting applied inside a helper three layers down is invisible in review; a capability block is where the next engineer looks. The exception is a case whose subject genuinely is the keyboard's assistive behaviour — then the setting belongs in that test, turned on deliberately and turned back off. ## A triage order that works 1. **Read the field back** and record the exact string you got, not a paraphrase of it. 2. **Classify it** against the three signatures above. Do not skip this; it decides everything after it. 3. **Change one setting** and re-run the same case. Changing two hides which one mattered. 4. **Check whether the string was awkward** — non-ASCII, long, or punctuated. If the failure appears only for awkward strings, that is a strong signal it is real rather than environmental. 5. **Confirm the Android lane is unaffected** before touching anything shared. If Android is green, the fix is an iOS-side setting and must not become a cross-platform change. ## What is not the fix here - **A sleep before or after typing.** The characters are not late; they are absent or altered. - **A retry.** A rate or autocorrection problem reproduces at whatever rate it reproduces, and a retry buys a green run that proves nothing. - **A hardware-key command.** Pressing physical buttons is a different mechanism and a different subject; it does not enter a string into a field. - **An Android capability.** Nothing in the Android drivers' typing surface applies to a WebDriverAgent session, and reaching for one in a review is a tell. ## The point worth carrying iOS text entry is not a byte transfer into a field; it is a trip through a keyboard that has opinions. Appium exposes those opinions as XCUITest settings — `maxTypingFrequency` for the rate, `keyboardAutocorrection` and `keyboardPrediction` for the rewriting, `useClearTextShortcut` for the emptying — and the diagnosis is entirely a matter of looking at how the resulting string is wrong before choosing which one to turn.

  • Why does the equivalent Android lane not need any of these settings?
    Because the Android drivers do not expose them. There is no typing-rate setting and no autocorrection switch on that side; the UiAutomator2 agent answers the send-keys command itself. The Android-side controls are different things entirely — the `appium:hideKeyboard` capability and the driver's own `mobile: type` and `mobile: replaceElementValue` methods.
  • When would you deliberately leave keyboard autocorrection switched on?
    When the case is about the keyboard's assistive behaviour rather than about the app — proving a species field accepts a corrected entry, or that a form survives a predicted completion. Turn it on inside that case and turn it off again, so the rest of the suite keeps a deterministic keyboard.

It is the difference between posting a letter and dictating one to an assistant who thinks they know what you meant: the message arrives, but somebody helpful has been editing it on the way.

saying these in an interview costs you the question

  • Retrying a mistyped entry instead of classifying the failure
  • Adding a sleep to fix altered characters
  • Looking for a typing-rate setting on Android
  • Changing several settings in one run
  • Calling an autocorrected string a device flake