

The way it works is by spawning a notifyutil process within the simulator runtime, which is then used to send a distributed notification across the iOS system that the Simulator listens for and toggles biometrics on (or off): Better still, it uses simctl and not AppleScript. A command line utility that controls many of the Simulator menu items, including biometrics. It didn’t take long for us to realise that simctl is nowhere near as powerful as ADB, but by chance, we did a quick Google search:Īnd lo, the first result was for a GitHub repo called AppleSimulatorUtils. This got us thinking about the iOS equivalent: simctl (part of xcrun ).
#Ios emulator mac 2018 android#
The difference though is that the Android biometric server controls the emulator using ADB ( Android Debug Bridge ), which can do lots of wonderful things, including simulating a successful biometric authentication. The Android team has also faced similar problems and came up with a similar solution using a local server instance to control the emulator. We have to thank our Android brothers and sisters for giving us a new path to follow. If we didn’t use AppleScript to automate biometrics, what did we use? We kept tweaking our scripts, but we kept getting strange, seemingly random errors, so we shelved the idea until we could come up with something more robust. The simulator has to be open (we usually ran in headless mode), and the simulator window has to be active otherwise the AppleScript would fail.
#Ios emulator mac 2018 code#
We found that our AppleScript code wasn’t super reliable, and required really specific setups. So this is it, right? This is the solution? Soon we had a proof of concept running and had a real UI test running that enabled and disabled biometrics in the app. Once we found out Xcode schemes can run a “pre” and “post” scripts to spin up the server and tear it down at the end, we got really excited. Spun up locally when the tests run, it would accept HTTP requests and can be called like any other network call, but sits outside of the simulator runtime, so it can execute AppleScript. Our engineers envisioned the concept of a biometric server a lightweight server instance. The really hard part was controlling the Mac with AppleScript from within UI tests since you can’t run AppleScript directly from within the iOS simulator. Initial investigations looked really promising, so we pursued it.


Since the menu needs to be clicked, we started to think about how we could control the Mac during automation tests.ĪppleScript is made for exactly this kind of thing, so we started playing around with scripting the macOS UI.

But we didn’t give up! Automate the automationĪfter failing to find anything useful in user defaults, we turned our attention back to the Simulator app. We trudged through all of the options but found nothing that would help us. The first thing we looked into was whether choosing “ Enrolled ” from the menu updated a user default setting for the Simulator app on macOS, so we fired up Terminal and typed in defaults read.
