App automation vs. Device Automation
Quamotion WebDriver provides two ways to automate apps running on iOS and Android devices: App Automation and Device Automation.
- Device Automation takes advantage of the built-in support for UI test automation in iOS and Android.
- App Automation uses an instrumentation technique, in which an automation library is injected into your app. This library is loaded
when your app launches, and Quamotion WebDriver interacts with your app using this library. Because your app bundle (
.ipafile) is modified, you need to have access to the original
.ipafile, and the app bundle needs to be resigned. Some applications may include anti-tamper protection which will detect app resigning and block the app from launching.
For this reason, we always recommend you try Device Automation first, and only switch to App Automation when required.
On iOS, App Automation and Device Automation boil down to these two options:
- Device Automation is based on the built-in UIAutomation tool that Apple provides and support. Appium, the Facebook WebDriverAgent, xcuitrunner, and the Quamotion WebDriver
in Device Automation mode all use the built-in Apple tools. You can recognize these tools because they report elements as
Device Automation and custom controls
Apps which contain custom controls, must ensure that these custom controls respect the Apple Accessibility Guidelines. Custom controls which fail to meet these guidelines,
will be recognized as
XCUIElementOther and very little information about these controls may be available to test automation scripts.
To quote the Accessibility Programming Guide for iOS:
If your application displays a custom view that contains other elements with which users interact, you need to make the contained elements separately accessible. At the same time, you need to make sure that the container view itself is not accessible. The reason is that users interact with the contents of the container, not with the container itself.
We generally recommend you use Device Automation on iOS, as there are a couple of limitations related to app automation:
- It is not the approach which is recommended/encouraged by Apple. There’s always a risk that Apple removes some of the functionality on which app automation relies, breaking app automation altogether from one version of iOS to another.
- App automation only works if you have the
.ipafile. This means app automation does not work:
- With applications which you’ve downloaded from the App Store
- With built-in applications (the home screen, Settings screen,… )
- App automation does not work for scenarios where your application switches to built-in or 3rd party apps. For example, even if you have the
.ipaof the app, but the scenario includes any of these actions, app automation will not work properly:
- Taking pictures using the camera app
- Sending/receiving text messages
- Connecting with Facebook/WhatsApp/… .
- App automation requires re-signing the application. This approach does not work with applications which, amongst others:
- Include anti-tamper protection
- Have special entitlements
- Have a special file format
- App automation injects custom code into the application (hence the name app automation). This can cause issues with applications:
- Which use 3rd party frameworks
- Which have special startup routines
In other words, in very specific corner cases (like apps which use custom controls, where the developers did not respect the Apple Guidelines) app automation may have an edge, these advantages are usually offset by the many limitations that app automation comes with.