fix(platform-apple): put --payload-url before the bundle ID on devicectl launch - #3017
Merged
Merged
Conversation
…ctl launch devicectl treats everything after the bundle identifier as the app's own argv, so --payload-url after it was silently delivered to the app as a launch argument instead of being honored as a URL to open. Physical-device `open <bundle-id> <url>` never actually opened the link. Fixes #2998
The devicectl launch fix moved --payload-url ahead of the bundle ID; this test still asserted the old (buggy) argv order.
Size Report
Startup median (7 runs, lower is better):
|
Member
Author
|
Reviewed at f916874. The fix looks right: CI: Smoke Tests is still queued. Nothing has failed yet. |
|
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
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.
Summary
devicectl device process launchtreats every argument after the bundleidentifier as the target app's own argv, not as
devicectloptions. Putting--payload-url <url>after the bundle ID (the previous order) meant the URLwas silently delivered to the app as a launch argument instead of being
opened as a deep link — physical-device
open <bundle-id> <url>neveractually opened anything.
The fix moves
--payload-urlbefore the bundle ID inlaunchCoreDeviceApp,matching how
devicectl's Swift ArgumentParser expects flags to precedepositional arguments.
Closes #2998
Touched files: 3 (1 source, 2 tests).
Validation
Tested commit:
f916874ed6(branchfix/ios-payload-url-order-2998).pnpm check:affected --run: all runnable checks passed — 428 test files,3090 tests, 0 failures (one earlier run hit the known contention-flaky
runner-artifact-reuse.test.tstimeout; passes standalone and passed cleanon rerun).
Live device check — physical iPhone "thymikee-iphone"
(
00008150-001849640CF8401C), drivingcom.apple.Preferencesvia a prefsdeep link (no other installed app exposed a safe URL-scheme target):
open com.apple.Preferences(no URL): Settings root list.open com.apple.Preferences "App-Prefs:root=General&path=About":lands on the "Apps" sub-screen, reachable only through the deep link.
landed back on Settings root); restoring the fix returned to the "Apps"
screen.
Targeted vitest: 47/47 passed with the fix; reverting only the source fix
fails 6 of them, confirming the tests catch the regression.
No unresolved risk: a 3-line argv reorder validated against
devicectl'sArgumentParser semantics, live device evidence, and unit tests.