iOS device support for STF

[renegadelink]

Hi all — I've been working on iOS support for STF. iPads and iPhones appear in the UI alongside Android devices: live screen in the browser, real touch, the usual remote-control flow. It's a fork and any feedback is welcome!

Repo / branch: https://github.com/renegadelink/stf/tree/ios-support
Docs: doc/ios-admin.md, doc/ios-architecture.md

What works

Capabilities are auto-detected per device depending on the state stf detects (example: is companion app running? is the device jailbroken?)

Capability axis	Unlocks
Lockdown only (any iOS 11+ device)	install/uninstall, reboot, syslog, screen stream, screenshot, app list, basic info
+ Developer services (iOS 17+ tunneld)	touch, keyboard, app launch/terminate, location spoof, hardware buttons (when screen backend allows)
+ Jailbroken (AFC2 or sshd)	rpcserver-based touch (root HID, survives DTX drops), SSH, shell, app dump, radio toggles, clipboard read
+ Web Inspector enabled	URL open via Safari Remote Automation as a DVT-free fallback

Screen capture picks a backend automatically based on the host: Valeria USB (H.264, 30–60 fps) on Linux, AVFoundation (CoreMediaIO) on macOS, with Accessibility / screenshotr fallbacks on either. The Linux Valeria path uses our screen-mirror pmd3 fork.

Try it

git clone https://github.com/renegadelink/stf.git
cd stf && git checkout ios-support
git submodule update --init --recursive
# Then follow doc/ios-admin.md — docker compose up, supply a signing cert
# for the XCTest companion, plug in a device.

The only piece an admin has to keep signed is the small STFTouchTests-Runner.app companion (Apple's normal 7-day free / 1-year paid cert lifetime applies). rpcserver and other on-device helpers are ad-hoc signed and don't expire.

Free-cert signing requires a Mac

If you're using a free Apple ID (no paid Developer Program membership), Apple only issues 7-day signing certs through Xcode's automatic-signing flow — there is no web portal or CLI for the free tier. So the first time signing step needs a Mac with Xcode: sign in under Preferences → Accounts, build any throwaway iOS app once against your Apple ID so Xcode generates a 7-day provisioning profile, then copy the resulting .mobileprovision and exported .p12 over to your STF host. Weekly refresh is the same dance. Paid Developer accounts skip this — fastlane sigh --force or the Apple developer portal both work from any OS, and the cert lasts a year.

Sharing logs

provider-ios, device-ios, and the companion log are the three useful sources; the troubleshooting doc has a per-symptom map. pmd3 invocations support --redact to scrub UDIDs / hostnames / possessive device names (e.g. <Owner>'s iPad) before pasting.

Feedback

• Does the auto-detected capability set match what your device should actually be able to do?
• iOS version + device model + which capabilities lit up (one-line reports are great).
• Companion install flow on developer-mode devices — clear, or did the cert/provisioning profile step dead-end you?
• Anything where a feature appeared in the UI but nothing happens.
• Frame rate / latency on Valeria (Linux) or AVFoundation (macOS) across host configurations - the frame rate changes based on how much of the screen is updating so you can expect that.

Not opening a PR yet — want real-world testing across more devices first. Thanks for taking a look.

[nanoscopic]

You do realize I did this already years ago right?

I abandoned the work because STF is a poor fit for iOS.

Did you at least look at my open source work doing this and start from there? It's a waste of time not to.

You probably need a short history lesson on iOS automation ( the version of it from my point of view ):

1. I was tasked by TMobile to add iOS support to STF
2. I did so for them, and this led to much tension with HeadSpin, who controlled STF at the time
3. This led to a hard fork of STF away from HeadSpin and the rebrand to DeviceFarmer. I'm the owner of the devicefarmer.com domain
4. Snapchat was an initial primary supporter of my work in this regard
5. I began to rewrite WebDriverAgent, because it sucks. That initial work is open source on my GitHub
6. After a lot of work with STF and WebDriverAgent I decided to go closed source and create a full rewrite of both
7. That full rewrite is called ControlFloor and is a fully working commercial product for several years now.
   6b. As part of that work I worked with and paid Daniel Paulus to release and extend the Go rewrite of his RE work for Sauce Labs, go-ios. go-ios is a joint effort by myself and him in that it is partly based on my own research I shared with him while paying him to do that work.
   6c. I was the first to open source xctest running. Shortly after I did Alibaba released their own private version doing so in tidevice ( since the cat was out of the bag then )
   6d. After tidevice and me, pymobiledevice3 began to copy the features from all of these projects.

In more recent history ( within last two years ) Sauce Labs began funding and steering go-ios, and Daniel Paulus doesn't really do much with it anymore.

Barely anyone in the iOS automation ecosystem gets along, and everyone is hiding their own private advancements on all of this stuff.

Many of us have private forks with extended features and/or entirely different private implementations written from scratch...

There are less than a dozen people in the world ( outside of Apple employees at least ) who understand all of this stuff sufficiently to put all the pieces together and advance them.

If your goal is to throw together crap using AI to do all this, you certainly can, but my advice would be as follows:

1. Don't base the main system on STF, it's terribly suited for this. It's somewhat reasonable to make an adapter to provide the devices out to STF. A shim if you will, but I would not tie in deeply to the lifecycle of STF.
2. Don't base it on pymobiledevice3. The feature support there is good but it's much slower than go-ios and ill-suited for building a farm imo. I personally don't like either pymobiledevice3 or go-ios, since I have my own private C code that I prefer, but of those two I'd reccomend go-ios.
3. Ask me to open source my rewrite of WDA and I'll consider it, because it's really quite terrible to continue basing everything on WDA.

[renegadelink]

You do realize I did this already years ago right?

I abandoned the work because STF is a poor fit for iOS.

Did you at least look at my open source work doing this and start from there? It's a waste of time not to.

Yup I saw your previous work. This fork has been working for me just fine though! The real test is having lots more devices which I can't test -_- . No worries if no one wants it. I can just leave it as a fork.

[nanoscopic]

You are certainly welcome to reinvent the wheel of much of what I did over the past 5 years... I can tell you there are a lot of random problems with making all of this crap work reliably, so fair warning to you.

Running 1-4 devices is pretty easy.

Running 20 devices off a single NUC or Mac Mini is quite another.

But hey, you have to start somewhere. Nobody else is really pushing this forward open source wise currently. The people doing stuff with the open source projects aren't really sharing imo.

[nanoscopic]

Another limitation of the free signing from Apple by the way is that you are limited to three installed custom apps at a time.

This can easily become a problem if you have a separate app for XCtest and video streaming ( through upload broadcast extension ).

Optimally everything the device farm stuff needs should be jammed into one app so it only eats up one of the three slots.

[renegadelink]

Wow thanks @nanoscopic ! I was not aware of all of that!! I'd say my goal is getting a good enough iOS support with AI. There isn't enough of a reason to spend months/years writing all of this by hand with what little free time I have now a days. I've used STF extensively with Android which I've always loved. Appium + WDA was always an awful experience compared to STF so this basically was an experiment how quickly AI could make a good enough STF support (it did not take that long to do). I appreciate the insight!

[nanoscopic]

Yeah STF works okay with Android ( although it remains a pain to setup initially imo )

That's why I had originally worked to add iOS support to it.

Also as part of that work I moved STF two major versions of Node forward, by hand. It took thousands of changes. The community refused to accept my PR because it was too big. That's when I threw in the towel and said no more. I sunk over a year into messing with STF.

It is, as you've noticed, now at least possible to quickly make a provider with AI. That was quite painful to do manually back in the day.

I don't want to discourage you making it all work with STF and making that better, as everyone definitely wants that. I just think it is suboptimal and is easy to make a way better system if you don't lock yourself into making it compatible with STF.

STF as a thing to get started makes sense, but I'd suggest a full new thing instead to really do it in a more polished way.
( eg: make a provider that can provider modularly to both STF and some brand new open source something )