Expect appium1.5 experience the new framework
Well you still need Node installed, yes.
Ah yes, update Node if you are able. I could go back and publish for an earlier version, but eventually we will be requiring newer versions of Node for appium, so may as well get a head start 
After Appium 1.5 is released, then this could be added in a minor release after that.
Hi Jonahss, I have upgraded node and npm ( to be node 5.3.0, and npm 3.3.12) but I still get the same error when trying to install appium-xcuitest-driver. Any thoughts on wht may be my problem?
npm install -g appium-xcuitest-driver
npm ERR! Darwin 14.5.0
npm ERR! argv “/usr/local/Cellar/node/5.3.0/bin/node” “/usr/local/bin/npm” “install” “-g” “appium-xcuitest-driver”
npm ERR! node v5.3.0
npm ERR! npm v3.3.12
npm ERR! code E404
npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/appium-xcuitest-driver
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.
npm ERR! Please include the following file with any support request:
npm ERR! /usr/local/lib/node_modules/appium-webdriveragent-driver/npm-debug.log
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-driver
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
1 Like
Hello again 
So I’m tracking this discussion since the beginning and still got some doubts. My main problem is: how to use (or test in my framework) different iOS drivers, when I using only Python client (Poor JS skills 
) . To sum up my question:
- Available iOS drivers:
-
https://github.com/appium/appium-xcuitest-driver - from what I understand this is wrapper of above driver adjusted to iOS driver. Currently, based on above comment it is not available on npm
-
https://www.npmjs.com/package/appium-ios-driver - this is also intresting. @jonahss - i see that you updated it couple days ago. Can I use it/test somehow with Python?
- New XCUITest driver will be delivered with Appium 1.5 behind a desired capability: automationName: ‘xcuitest’ right?
Please, help me understand how I can test those drivers withou installing 1.5 beta.
Regards,
Stefan
UPDATE: I was searching answers for my question how to handle those different types of drivers in iOS tests. Only topic is here: http://stackoverflow.com/questions/31990494/different-types-of-drivers-automation
but i still can’t get it
i would appreciate if someone help me to make it clear.
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.
3 Likes
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 git.
1 Like
Hi @Tree thanks for helping us test xcuitest driver.
You don’t need the ‘automationName: xcuitest’ if you’re running the xcuitest driver by itself. That desired capability will only be added for the main Appium driver, so it can know which driver (regular ios or xcuitest) to proxy commands to.
I think your problem right now is that the xcuitest driver does not recognize the /timeouts endpoint and is responding with an error. The test should continue just fine, but your test script may be exiting when it hits the error after sending a timeout command.
Please respond with more bugs and bug reports by creating issues on the github repository for xcuitest. Appium discuss is usually for general discussion, and not for technical debugging.
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?
Hi @appium
Yes you are correct that XCUITest will not work on versions of iOS prior to iOS 9. For older versions of iOS, users can still use Instruments. Keep your older versions of Xcode, so that once Apple removes Instruments support you will still be able to run tests.
We don’t know Apple’s timeframe at all 
It would be really useful for us all if we could get an answer from Apple. I will try sending them a message, but if you (and others) post bug reports to Apple asking about it maybe they will answer us.
findElementByIOSUIAutomation is something I hadn’t thought about. You are right, with XCUITest, this locator strategy will not be available at all.
Hopefully the new API in XCUITest will be more reliable and you can just use the regular Appium findBy methods. If you come up with specific cases where you cannot locate an element, create an issue on the appium-xcuitest-driver repository on github and we can figure out how to solve the issue.
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
Thanks @jonahss
I’m more interested in the appium-xcuitest driver. Where can I get more information on that and are there any samples in using that driver?
Btw, I was also cheking this space: https://forums.developer.apple.com/thread/14063
Any progress on your request to Stefan Lesser? That will immensely help us in leveraging XCUITest alongside with Jenkins.
Thanks.