Appium 4's fourth beta drives a real iPhone through a tunnel with no Xcode on the driving machine at all; phoneshell's own bootstrap still calls xcodebuild at step 4 of six
Appium's fourth Appium 4 beta lets its XCUITest driver open a tunnel to a real iOS device from any host, Mac or not, and drive it with no Xcode in that loop. The catch is in one clause of the same release note: WebDriverAgent has to already be on the phone. phoneshell's own bootstrap still needs Xcode to put it there.
The fourth beta of Appium 4 shipped on 9 October 2026, according to a vendor writeup from TestMu AI, the only dated source we found for that specific beta; we could not independently confirm the date against Appium's own GitHub release notes, so treat it as single-sourced. The release modernizes the project end to end: Appium 4 refuses to start on Node 20, requiring 22.22 or newer on the 22 line, 24.15 or newer on the 24 line, or Node 26 and up, and every @appium/* package, including appium itself, ships ESM-only with no CommonJS build, so a plain require() call now fails. The CLI drops --allow-cors (replaced by --allow-insecure=*:cors or --relaxed-security), drops --nodeconfig along with Selenium Grid 3 registration entirely, and no longer installs drivers or plugins at npm install time; those now go through appium driver install or a package.json declaration. There is no GA date. Betas are landing weekly.
What changed, and when
The specific change worth isolating is in the XCUITest driver's own Appium 4 beta: real iOS or tvOS 18+ devices can now be driven with no Xcode at all, using a new library called appium-ios-remotexpc, after a tunnel is started with sudo appium driver run xcuitest tunnel-creation. On a host that is not running macOS, appium:udid and appium:platformVersion become required capabilities, and WebDriverAgent must either be pre-installed on the device already or reachable through appium:webDriverAgentUrl. Driving a simulator is unaffected by any of this and still requires macOS, since there is no such thing as an iOS simulator anywhere else.
Read closely, the claim is narrower than "Appium no longer needs Xcode for iOS." It is "the control loop no longer needs Xcode, provided WebDriverAgent already exists on the device." Getting WDA onto a device in the first place is still, as far as the public tooling goes, an Xcode-shaped problem: WDA is an XCTest bundle, and XCTest bundles are built, signed, and installed through Apple's own toolchain. What beta 4 removes is the requirement that the machine doing the ongoing tapping, typing, and reading also be the machine that holds Xcode.
Six steps, and two of them say Xcode
phoneshell's own bootstrap, documented directly in phoneshell/device.py's module docstring, lays out exactly where a Mac with Xcode is load-bearing. Step 1 is "Xcode selected," because devicectl, the detached launcher phoneshell prefers, only ships with Xcode and not with the Command Line Tools alone; the docstring notes this is why DEVELOPER_DIR has to point at a full Xcode install. Step 4 is "WDA built + signed," and the code backing it calls xcodebuild test-without-building directly against a project checked into the Blomega team's own signing setup. Only step 6, launching WDA detached with xcrun devicectl device process launch so nothing on the Mac has to stay attached, resembles what Appium 4 beta 4's tunnel is doing: driving a device that is already instrumented, without holding a build tool open for the whole session.
For comparison, the pattern this site has already documented for driving a phone with zero on-device instrumentation at all is physical, not a tunnel: an ESP32 microcontroller pressing the touchscreen from outside, with no Xcode and no accessibility tree in the loop because there is no WDA session to begin with (covered here). Appium 4 beta 4's approach is the opposite trade: it keeps WDA, and the rich accessibility-tree access that comes with it, and removes only the Mac that would otherwise have to sit between the test script and the tunnel.
| Dimension | Appium 4 beta 4 (XCUITest, non-macOS host) | phoneshell bootstrap | Source |
|---|---|---|---|
| Host OS to drive a real device | Any OS; appium-ios-remotexpc tunnel is the only requirement | macOS with Xcode installed and selected (step 1) | testmuai.com; phoneshell/device.py |
| Xcode needed to build/sign WDA | Not addressed; assumes WDA already installed | Yes, step 4 calls xcodebuild test-without-building directly | phoneshell/device.py |
| Launch mechanism once WDA exists | Tunnel via appium-ios-remotexpc, no build tool held open | xcrun devicectl device process launch, detached (step 6) | testmuai.com; phoneshell/device.py |
| Simulators | Still require macOS, unaffected by this beta | Not used; phoneshell drives only physical hardware | testmuai.com; phoneshell houseFacts |
| Stability | Fourth of weekly betas, no GA date announced | Default launcher is "auto", with devicectl/dvt/xcodebuild as explicit fallbacks | testmuai.com; phoneshell/cli.py |
What it means for anyone driving a real iPhone from something other than a Mac
- Beta 4 is good news specifically for the control loop, not the setup. A CI runner on Linux could, in principle, hold open an Appium session against a physical iPhone all day with no Xcode license, no macOS VM, and no build step in sight, as long as something else put WDA on that phone first.
- That "something else" is still, in practice, a Mac running Xcode, the same machine phoneshell's steps 1 and 4 require. Nothing in the beta 4 reporting we found describes a non-Xcode path to building and signing WDA itself; the tunnel is a way to stop depending on that machine after the fact, not a way to avoid it.
- phoneshell's own launcher choice (
auto | devicectl | dvt | xcodebuildincli.py) already treats "hold a build tool open" and "launch something already built" as different operations, the same distinction beta 4's tunnel draws. phoneshell has simply never had a reason to move the second half off the Mac, because its Mac is already there for the first half. - Simulators are the one place this beta changes nothing for anyone: there is no tvOS or iOS simulator outside macOS, so any workflow that needs simulated devices rather than physical ones gets no benefit from a non-Mac host regardless of which driver version it runs.
Check it yourself
# Appium 4 beta 4's own claims (single-sourced; check the project's own notes directly)
curl -s https://www.testmuai.com/blog/whats-new-in-appium-4/ | grep -i "remotexpc\|tunnel-creation\|beta 4\|October"
# Appium's own release history, to confirm or correct the 9 October 2026 date:
curl -s https://github.com/appium/appium/releases | grep -i "4.0.0-beta"
git clone https://github.com/Blomega/phoneshell && cd phoneshell
sed -n '1,25p' phoneshell/device.py # the six-step bootstrap, in the module's own words
grep -n "xcodebuild" phoneshell/device.py phoneshell/cli.py # every place Xcode is load-bearing
grep -n "\"auto\"\|devicectl\|\"dvt\"\|\"xcodebuild\"" phoneshell/cli.py # the four launcher choices
What would prove this wrong
We claim Appium 4 beta 4's no-Xcode tunnel still requires WebDriverAgent to be pre-installed by some other, Xcode-dependent process. That is wrong the moment the XCUITest driver's own documentation describes a way to build, sign, and install WDA onto a real device without Xcode anywhere in that chain; we found none as of 23 October 2026. We also report the 9 October 2026 beta 4 date as single-sourced from a vendor blog; that is wrong if Appium's own GitHub releases page gives a different date, which we were unable to load directly in this check and will revisit by 31 January 2027.
Sources
- TestMu AI, What's New in Appium 4, beta 4 dated 9 October 2026, read 23 October 2026.
- Blolabel, phoneshell/device.py, module docstring and WDA build/launch functions, read 23 October 2026.
- Blolabel, phoneshell/cli.py, launcher option handling, read 23 October 2026.
- Blolabel, A $7 ESP32 drives a real iPhone with no Xcode and no accessibility tree, for the contrasting hardware-only approach, read 23 October 2026.