[iOS9 UIAutomation] What is Appium approach to UIAutomation deprecation by Apple

Hi Jonahss,

npm was unable to find the driver package. Do I need to update to a newer npm?
I get the error message below. Any thoughts on how to get this to install?

/tmp/webdriver $ npm install -g appium-xcuitest-driver
npm ERR! Darwin 14.5.0
npm ERR! argv "node" "/usr/local/bin/npm" "install" "-g" "appium-xcuitest-driver"
npm ERR! node v0.12.6
npm ERR! npm v2.12.1
npm ERR! code E404

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/appium-xcuitest-driver8
npm ERR! 404
npm ERR! 404 'appium-xcuitest-driver' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

I think it was a wrong link provided. There is no 'appium-xcuitest-driver' as a registered npm package.
I've found this one https://www.npmjs.com/package/appium-webdriveragent-driver21
So maybe npm install appium-webdriveragent-driver should work.

update no the npm install appium-webdriveragent-driver is not having automationName: 'xcuitest' as an option. So seems like the correct npm (appium-xcuitest-driver) is just not available as package to install at the moment

Ok here we go. Welcome to the new year everybody

My bad about not having npm install appium-xcuitest-driver working. The package.json file still had the old module name in it, so it didn't publish. Should be good to go now.

The new appium 1.5 architecture is to have a main Appium driver, which runs as a server and forwards sessions to other drivers within it. Examples of these drivers would be appium-ios-driver and appium-android-driver. Those driver can in turn proxy commands to other drivers they spawn, like appium-chromedriver and appium-safari-driver. Each of these drivers inherits from a BaseDriver class. Drivers can be run as individual standalone servers, or can be called programmatically from another Nodejs program.

So appium-ios-driver, appium-webdriveragent-driver, and appium-xcuitest-driver all extend the BaseDriver class. Right now, appium-ios-driver is included in appium 1.5 and all iOS tests get send to this driver. We will be including appium-xcuitest-driver (and possibly later appium-webdriveragent-driver) into appium behind special desired capabilities (automationName: "xcuitest"). At a certain point, we will deprecate the ios-driver and replace it with xcuitest-driver since Apple is deprecating Intruments.

Hi Jonahss,

I was just able to install the appium-xcuitest-driver, but it has an issue when I try run a test.

Exception captured when calling Before method of hook: DriverInfo. - Exception: [A new session could not be created. Details: The desiredCapabilities object was not valid for the following reason(s): automationName xcuitest is not included in the list. (33)]

Have I missed a setup step maybe or is the npm module not up to date still?

I tried omitting the automationName: xcuitest from my capabilities and I can get further(also tried adding xcuitest to the desired-caps.js file inside the appium-base-driver package - with the same end result). It will launch a simulator and open my app. But as soon as the app is ready to interact with I get an error. It may be a problem with localhost on my machine but i'm not really sure). As in order to get the webdriveragent-driver to be accessible from the machine I run the tests on (im running the tests over the network), I had to change the default host address in index.js to my mac's ipaddress.

An excerpt of the error is as below.

'info WebDriverAgent Jan 13 12:28:42 AUK-PDMAC29 XCTStubApps[1136]: Built at Jan 13 2016 12:26:23
info WebDriverAgent 
info WebDriverAgent Jan 13 12:28:42 AUK-PDMAC29 XCTStubApps[1136]: WebDriverAgent started on port 8100
info WebDriverAgent 
info WebDriverAgent-driver detected that WebDriverAgent is running at url http://10.28.244.237:8100
info WebDriverAgent Jan 13 12:28:42 AUK-PDMAC29 XCTStubApps[1136]: ServerURLHere-        >http://10.28.244.237:8100<-ServerURLHere
info WebDriverAgent 
info WebDriverAgent-driver WebDriverAgent started at url http://10.28.244.237:8100
info JSONWP Proxy Proxying [POST /session] to [POST http://localhost:8100/session] with body:     {"desiredCapabilities":{"app":"/Users/Shared/Apps/FIPhone.app","bundleId":"com.fiserv.ubank"}}
info JSONWP Proxy Got response with status 200: {"value":{"capabilities":{"device":"iphone","browserName":"uBank Dev","sdkVersion":"9.1","CFBundleIdentifier":"com.fiserv.ubank"}},"sessionId":"DD388F24-9C24-4893-86FE-14560FE73D96","status":0}
info MJSONWP Responding to client with driver.createSession() result:    {"appPackage":"nz.co.mcom.phone","platformName":"iOS","autoAcceptAlerts":"true","app":"/Users/Shared/Apps/FIPhone.app","deviceType":"iPhone","devic...
info HTTP <-- POST /wd/hub/session 200 37075.029 ms - 261 
info HTTP --> POST /wd/hub/session/c6e07e2a-d427-4097-8616-09b875606d01/timeouts 
info MJSONWP Driver proxy active, passing request on via HTTP proxy
info JSONWP Proxy Proxying [POST /wd/hub/session/c6e07e2a-d427-4097-8616-09b875606d01/timeouts] to [POST http://localhost:8100/session/DD388F24-9C24-4893-86FE-14560FE73D96/timeouts] with body: {"type":"implicit","ms":3000}
info JSONWP Proxy Got response with status 200: {"value":"Unhandled endpoint: /session/DD388F24-9C24-4893-86FE-14560FE73D96/timeouts -- http://localhost:8100/ with parameters {\n    wildcards =     (\n        \"session/DD388F24-9C24-4893-86FE-14...
info JSONWP Proxy Replacing sessionId DD388F24-9C24-4893-86FE-14560FE73D96 with c6e07e2a-d427-4097-8616-09b875606d01
info HTTP <-- POST /wd/hub/session/c6e07e2a-d427-4097-8616-09b875606d01/timeouts 200 8.915 ms - 293`

Hi @Tree Appium dev team will be able to help you much better if you could log this as an issue at git19.

Hi @jonahss,

Your input is awesome.
We're working on building an iOS/Android automation framework and wanted to check with you on this. Our biggest concern is Apple deprecating Instruments which comprises UIAutomation framework. How does this all come thru with Appium? Even though the majority of the mobile methods we're using are the regular find methods, we also call into findElementByIOSUIAutomation method. So, we would have to rewrite all of our iOS test cases to use the new XCUITest framework and call them from Appium? or bypass Appium completely and execute the XCUITests thru XCode plugin from Jenkins CI?. We don't want to maintain 2 different code bases (XCUITest with iOS and the regular Appium/Selenium methods written in Java when working on Android).

Please advise us. Is there a timeframe on when Apple would deprecate Instruments for good?
Btw, the new XCUITest doesn't work with iOS 8 and below. So, there we are with another dilemma.

We're totally confused here and any clarifications would be great.

Anybody have any pointers?

Thanks @jonahss

With Appium 1.5 release imminent, will it support calling test cases written in objective-c/swift from XCode using XCUITest and return the results of each of the test case run back to Appium?

or, I'm curious to know more about the automationname: xcuitest or the new xcuitest driver. what is this all about?

Can you please explain?

Thanks for your wonderful support.

Appium 1.5 will have no new features. It is a major architectual refactor of the code.

So Appium 1.5 will still use the same Instruments approach that appium 1.4.16 uses today.

After Appium 1.5, we will be able to add the appium-xcuitest-driver. At first it will be a 'beta' feature, so users will have to send automationName: xcuitest to use Xcuitest instead of Instruments. This could be added maybe in two months?

After we are sure that there are no bugs in xcuitest-driver and it has all the features of the old ios driver, we will switch the default driver for all iOS jobs to the xcuitest driver. This probably will not happen for about 3 or 4 months from today.

For now, users can install or clone the appium-xcuitest-driver and test it by itself.

The appium-xcuitest-driver uses the same Mobile JSON Wire Protocol that Appium and Selenium have always used. Your tests should not need to be changed at all except that findElementsByIOSUIAutomation will no longer be implemented. Right now there is no plan to add the ability to write custom tests in objective-c/swift. If there is a feature that needs to be implemented, please create an issue on the appium-xcuitest-driver repository on github.

Thanks @jonahss

Going forward, instead of findElementByIOSUIAutomation, it would be great if you add support for calling into XCUITest test cases written with Objective-C/Swift and parse the results from within Appium supported languages (java, python etc). In this way, we get a huge benefit. The test cases would be very fast on iOS as we're using Objective-C/Swift to write the test cases in XCUITest framework. This is very similar to findElementByIOSUIAutomation call which accepts javascript code leveraging Apple UIAutomation framework.

Just my 2 cents.

Yes, I understand that. Noting your request.

But this would require us to write a Swift parser and executor in Swift. Last time we were using javascript so we could call eval(). On Android, I had to write a recursive descent parser and use Java Reflection to create a way to dynamically run the Android UIAutomator selector. It was a Java compiler written in Java. This was fun, but I had to hard-code support for only a couple Java classes and functions.

The Webdriver api should really be able to provide the means to do everything you want to do with testing. Here at Appium, we want to create methods to perform standard test actions, and don't mean to give users way to execute arbitrary code.

If you want to run plain old XCUITests on an app, then I suggest using Xcode and just having a native XCUITest suite.

If you find something that you can do with XCUITest, and you can't find a way to do it with appium-xcuitest-driver (or our method is too slow), then let's look at each of these cases individually and see if we can create new methods to help