release: v0.4.11 — stop hijacking the foreground, fix real-device terminate

[justrach]

Why this release exists

kuri could not be run on a machine someone was using. Driving the Simulator seized the foreground window and moved the cursor — on every tap, and every 250ms during a wait-for-ui. That is fixed, along with two real-device bugs that the new tests surfaced.

---

kuri no longer takes over your machine

Every input command called sim_window.activate first. It had to: CGEventPost(kCGHIDEventTap, …) injects into the global event stream, so events land wherever focus happens to be, and Simulator.app had to be raised for a tap to hit the right thing.

Command	Before	Now
tap doubletap longpress swipe gesture touch key key-sequence batch	global HID tap → had to raise the window and warp the cursor	CGEventPostToPid → straight into Simulator's queue
type	AppleScript keystroke → goes to the frontmost app	Unicode CGEvents addressed to the pid
uitree find wait-for-ui	called activate()	nothing — AX reads work on a background app
button background	called activate()	nothing — already used AXPress, which never needed focus
open-sim	open -a (raises it)	open -g (background)

type was the worst of them: because AppleScript keystroke targets whatever is frontmost, it had to steal focus to be correct — and if it ever ran without doing so, it would have typed your text into whatever you had open. wait-for-ui was a close second, re-stealing the foreground on every poll for the length of the wait.

--activate restores the old behaviour per command, off by default.

Real-device fixes

terminate --device could never have succeeded. It built:

devicectl device process terminate --device <udid> <bundle-id>

but devicectl's terminate takes --pid and accepts no bundle id at all, so every invocation died on devicectl's own argument parser. Now:

$ kuri-mobile ios launch --device --udid <UDID> com.apple.Preferences
pid=40728
$ kuri-mobile ios terminate --device --udid <UDID> --pid 40728     # exit 0
$ kuri-mobile ios terminate --device --udid <UDID> com.apple.Preferences
terminated pid=40731

The bundle-id form resolves a running pid by matching device info processes against the app's on-device bundle URL. A launch that reports success without an identifier is now an error rather than a silent zero — which would otherwise terminate an unrelated process later.

list-apps --device silently hid every system app. devicectl device info apps defaults to developer apps only and nothing in the output says so, so a command documented as "list installed apps" returned a handful of entries on a phone with hundreds, and exited 0. The same defaulting broke bundle-id lookups, so terminate-by-bundle-id could not resolve a system app either.

list-apps on the simulator no longer demands --udid — it resolves the booted simulator like every other simulator command already did.

Diagnosis

"Simulator.app is not running" when it was running. The accessibility tree hangs off a window, and simctl boot does not open one — so a running-but-windowless Simulator produced an error that sent you to restart an app that was already up. Now a distinct SimulatorHasNoWindow error carrying the real remedy, and doctor reports window presence rather than just the process.

Tests

• zig build e2e-ios-device — new suite against attached hardware. Inspection, the install → list-apps → launch → terminate → uninstall round trip both by pid and by bundle id, and assertions that the XCUITest-only commands still refuse cleanly while a real device is attached. Skips with a reason when nothing is plugged in, no bundle id is set, or the screen is locked — phones re-lock on their own timeout and SpringBoard refuses every launch while they are, which is the environment, not a defect.
• 21 hermetic real-device contract cases in e2e-ios, needing no hardware. They pin the silent-success class fixed in 0.4.10. Two assert the absence of devicectl's argument-parser complaint — that is what separates "the device is missing" from "we called devicectl wrong", i.e. exactly the terminate bug above.
• e2e-ios degrades instead of failing on preconditions a machine cannot supply (Accessibility grant, Simulator window, Xcode toolchain), which is what lets it be a CI gate rather than a permanent red build on a runner that can never hold a TCC grant.
• More simulator coverage: list-apps, status-bar, ui appearance set-and-read-back, set-location/reset-location, log --last, terminate.
• devicectl's JSON shapes are unit-tested against fixtures — a missing pid must not decode as 0, and /var/Demo.appendix must not match as being inside /var/Demo.app.

Verified

Suite	Result	Against
e2e-ios-device	24 passed, 0 failed	iPhone 16 Pro Max, physically attached
e2e-ios	54 passed, 0 failed	booted iPhone 17 Pro simulator
e2e-ios (headless)	44 passed, 0 failed, 1 skipped	AX group skips without a Simulator window
zig build test	42 passed	—

Not verified: the pid-targeted input path. CGEventPostToPid and the Unicode type compile and are the correct APIs for background delivery, but no tap/swipe/type has been run against a simulator since the change — the e2e suites deliberately never post input events, since doing so seizes the cursor of whoever is running them.

CI

The e2e suite finally runs on every push. A new mobile-macos job builds kuri-mobile, runs its unit tests, boots a simulator and runs both suites. Nothing previously caught a regression on the device path — which is how the silent --device no-op survived from 0.4.6 to 0.4.10.

It picks and boots the simulator through kuri-mobile itself rather than xcrun simctl: partly to exercise list-devices and boot for real, and partly because bare xcrun resolves through xcode-select, the exact indirection whose failure mode this project exists to avoid. The job never opens Simulator.app, so it runs headless and the accessibility cases skip.

kuri-mobile's unit tests now also run on the Linux job — it has its own build.zig, so the root test step never reached them.

🤖 Generated with Claude Code

https://claude.ai/code/session_012gzdKWXk7UbHm5TtSGqYBJ