fix(ios): name Developer Mode and pairing as the real launch blockers - #1527
Merged
Conversation
A freshly paired iPhone that is unlocked, trusted and reported by Xcode as available (paired) still cannot launch anything while Developer Mode is off. The failure surfaced as a disk-image mount error carrying the default hint, which tells the user to check that the device is unlocked, trusted and visible in Xcode — all of which were already true. devicectl knows the actual cause and says so: 'The operation failed because Developer Mode is disabled.' Map that failure, and the unpaired one, onto hints that name what to do. The pairing hint also mentions the device passcode, without which tapping Trust leaves the device unpaired. Observed on a real iPhone 13 that had never been used for development.
Size Report
Startup median (7 runs, lower is better):
Top changed chunks: no changes in the largest emitted chunks. |
Member
Author
|
Reviewed exact head |
thymikee
added
the
ready-for-human
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while running the #1521 hardware matrix on a second iPhone that had never been used for development.
The problem
The device was unlocked, trusted, and reported by Xcode as
available (paired). Every launch still failed:Every instruction in that hint was already satisfied, so it sends you to re-check the things that are fine. The actual cause is stated plainly by devicectl:
Developer Mode being off is the normal state of a phone that has never been used for development, so this is the first thing a new device hits — and the one thing the hint never mentions. The product already understands the concept: runner startup has a
verify_developer_modestep, andcli-helpdocuments "have Developer Mode enabled". It just never reached this failure path.Change
Two cases added to
resolveIosDevicectlHint, which already maps specific devicectl failures to specific advice:Unrecognised failures still fall through to the default hint.
Verification
Not just unit-tested — checked against the real device that was failing:
Unit tests cover both new cases, the "must be paired" text captured verbatim from the live unpaired run, and that an unrecognised failure still returns null.
pnpm check:affected --runpasses except provider-integration Android timeouts that pass 21/21 in isolation — the known contention signature, in modules this diff does not touch (it changes hint strings only).