Can't send keys to elements in iOS after Xcode update

macOS Mojave 10.14.16 running in a MacBook Pro 2018
Xcode 11.1
Simulator 11.1

Hi guys!

We’re having issues with our tests since the last Xcode update. We’re running integration tests in Ruby with Xcode. Basically, using find_element(:accessiblity_id, foo).type isn’t working in most cases. This method is working when the element is a XCUIElementTypeTextField, but isn’t working when the element is a XCUIElementTypeCell with children and one of those children is the XCUIElementTypeTextField we’re trying to send keys to.

Before the last update these methods could point correctly to these elements and fill them, but now trying to type in them breaks the test giving this error logs:

In Appium

http://localhost:8100/session/A318D28D-EA2C-4A52-A236-E31BE6B955A9/element] with body: {“using”:“accessibility id”,“value”:“First Name *”}
[WD Proxy] Got response with status 200: {“value”:{“ELEMENT”:“43010000-0000-0000-4092-000000000000”,“element-6066-11e4-a52e-4f735466cecf”:“43010000-0000-0000-4092-000000000000”},“sessionId”:“A318D28D-EA2C-4A52-A236-E31BE6B955A9”}
[W3C (7d1700d7)] Responding to client with driver.findElement() result: {“element-6066-11e4-a52e-4f735466cecf”:“43010000-0000-0000-4092-000000000000”,“ELEMENT”:“43010000-0000-0000-4092-000000000000”}
[HTTP] ← POST /wd/hub/session/7d1700d7-1c26-4275-816b-49cb658bc158/element 200 836 ms - 137
[HTTP] → POST /wd/hub/session/7d1700d7-1c26-4275-816b-49cb658bc158/element/43010000-0000-0000-4092-000000000000/value
[HTTP] {“value”:[“W”,“i”,“z”,“a”,“r”,“d”],“text”:“Wizard”}
[W3C (7d1700d7)] Calling AppiumDriver.setValue() with args: [[“W”,“i”,“z”,“a”,“r”,“d”],“43010000-0000-0000-4092-000000000000”,“7d1700d7-1c26-4275-816b-49cb658bc158”]
[XCUITest] Executing command ‘setValue’
[WD Proxy] Matched ‘/element/43010000-0000-0000-4092-000000000000/value’ to command name ‘setValue’
[Protocol Converter] Added ‘text’ property “Wizard” to ‘setValue’ request body
[WD Proxy] Proxying [POST /element/43010000-0000-0000-4092-000000000000/value] to [POST http://localhost:8100/session/A318D28D-EA2C-4A52-A236-E31BE6B955A9/element/43010000-0000-0000-4092-000000000000/value] with body: {“value”:[“W”,“i”,“z”,“a”,“r”,“d”],“text”:“Wizard”}
[WD Proxy] Got an unexpected response with status 500: {“value”:{“error”:“unknown error”,“message”:“An unknown server-side error occurred while processing the command”,“traceback”:“”},“sessionId”:“A318D28D-EA2C-4A52-A236-E31BE6B955A9”}
[W3C] Matched W3C error code ‘unknown error’ to UnknownError
[WD Proxy] Matched ‘/element/43010000-0000-0000-4092-000000000000/attribute/type’ to command name ‘getAttribute’
[WD Proxy] Proxying [GET /element/43010000-0000-0000-4092-000000000000/attribute/type] to [GET http://localhost:8100/session/A318D28D-EA2C-4A52-A236-E31BE6B955A9/element/43010000-0000-0000-4092-000000000000/attribute/type] with no body
[WD Proxy] Got response with status 200: {
[WD Proxy] “value” : “XCUIElementTypeCell”,
[WD Proxy] “sessionId” : “A318D28D-EA2C-4A52-A236-E31BE6B955A9”
[WD Proxy] }
[W3C (7d1700d7)] Encountered internal error running command: UnknownError: An unknown server-side error occurred while processing the command. Original error: An unknown server-side error occurred while processing the command
[W3C (7d1700d7)] at errorFromW3CJsonCode (/Applications/
[W3C (7d1700d7)] at ProxyRequestError.errorFromW3CJsonCode [as getActualError] (/Applications/
[W3C (7d1700d7)] at JWProxy.getActualError [as command] (/Applications/

In the shell (running tests via zsh):

/usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/common/element.rb:154:in send_keys' /usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/w3c/bridge.rb:373:in send_keys_to_element’
/usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/w3c/bridge.rb:552:in execute' /usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/bridge.rb:166:in execute’
/usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/appium_lib_core-3.2.3/lib/appium_lib_core/common/base/http_default.rb:81:in call' /usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/http/default.rb:104:in request’
/usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/http/common.rb:84:in create_response' /usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/http/common.rb:84:in new’
/usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/response.rb:32:in initialize' /usr/local/Cellar/ruby/2.6.5/lib/ruby/gems/2.6.0/gems/selenium-webdriver-3.141.0/lib/selenium/webdriver/remote/response.rb:69:in assert_ok’
at JWProxy.getActualError [as command] (/Applications/
at ProxyRequestError.errorFromW3CJsonCode [as getActualError] (/Applications/
at errorFromW3CJsonCode (/Applications/
UnknownError: An unknown server-side error occurred while processing the command. Original error: An unknown server-side error occurred while processing the command
Error: test_wizard_forms(WizardForms): Selenium::WebDriver::Error::UnknownError: An unknown server-side error occurred while processing the command. Original error: An unknown server-side error occurred while processing the command

Since the last Xcode update broke several things including our tests system (and our app itself :P) we were waiting for the Appium 1.15.1 release, but this bug hasn’t changed. As a possible solution I thought I could try to filter the element with both its accessibility_id and its class, but I didn’t find a proper way to do this. If I filter through the class I would obtain many elements on-screen (the many fields shown on it) but I’m stuck on picking the correct one out of them. Filtering through the accessibility_id is what I stated above.

I’m not exactly sure this is the proper bug’s cause but in terms of functionality it somehow makes sense: the login fields, for instance, are elements without children (they lack static text) and Appium successfully send keys to them. In more complex elements (with children) the accessibilty_id doesn’t point directly to the XCUIElementTypeTextField and the test crashes with the log shown above. At the same time, I’m surprised there hasn’t been other reports regarding this issue since this change has broken all our tests that involve sending keys to fields, which make 60% of our integration tests.

Any idea on how can we tackle this bug? I’m sorry if I’m missing information that could be relevant, please do ask for it if this is the case.

Thanks a lot and regards!


yes, this the change and xctest and you need to update your locators, so the setValue command is set to the proper TextField element instead of a Cell.

I would recommend using predicate or class chain locators, since these are still fast enough and provide the necessary flexibility.

let say for a text field with the given id the predicate locator would be:

type = 'XCUIElementTypeTextField' AND name = 'fieldId'

For a text field inside a cell the class chain locator might look like

**/XCUIElementTypeCell[`name = 'cellId'`]/**/XCUIElementTypeTextField[`name = 'fieldId'`]

Hi Mykola! I’ve been trying many things these last weeks and I finally found a way to make it work. I used class_chain indeed, I simply removed the name in the child element since I just needed to point the child element of that type (also the child doesn’t have name on its own).

I also needed to add the colon and space that wasn’t in the id but on the name, for that reason my line looks like this:

find_element(:class_chain, "**/XCUIElementTypeCell[name = "#{field}: "]/**/XCUIElementTypeTextField").type(value)

I still have to check all the tests but thanks very much!!!