[masaaki-hori]

Problem

mobile: launchApp is the XCUITest way to relaunch an app with arguments / environment
(e.g. the --vm-service-port / --disable-service-auth-codes flags that appium:dartVmServicePort
relies on since #933), but it is not usable through this driver:

• In the FLUTTER context it is not proxied and ends up as Command not supported.
• From NATIVE_APP the app relaunches, but the Dart VM socket keeps pointing at the old process.

Fix

mobile: launchApp now takes the same cross-context path as mobile: activateApp: it is proxied to
XCUITest from any context and then reConnectFlutterDriver runs, honoring skipAttachObservatoryUrl.
activateApp is unchanged.

The README lists mobile:launchApp among the cross-context commands, with an example of relaunching
with the dartVmServicePort flags.

Tests

Added driver/test/mobile-launch-app.test.mjs, which calls FlutterDriver#executeCommand in the
FLUTTER context and asserts that mobile: launchApp is forwarded to the proxy driver and followed by
a reconnect (or not, with skipAttachObservatoryUrl). Both cases fail on the current main and pass
with this change.

🤖 Generated with Claude Code

[KazuCocoa]

Did you try out flutter:launchApp?

Launch the app with flutter:launchApp for iOS and attach to the Dart VM: for users whom application under test do not print the observatory url via regular launch/activate app method

https://github.com/appium/appium-flutter-driver#several-ways-to-start-an-application

[masaaki-hori]

Yes, I looked at it, but it doesn't cover this case. Checked against the instrument-service path it uses:

• flutter:launchApp goes through appium-ios-device's instrument service (usbmuxd), which the README scopes to iOS real devices. With a simulator UDID, services.startInstrumentService() throws Could not find the expected device '<udid>', and launchApp() catches that and returns false, so the command goes on to reconnect without having launched anything. It also relies on internalCaps.udid, which is unset unless the client passes udid explicitly; in that case the same call fails with Could not find the expected device 'undefined'.
• More importantly, this PR is about consistency rather than a missing launch method: processArguments from the session capabilities (including the flags dartVmServicePort injects since fix(ios): forward dartVmServicePort launch flags to XCUITest #933) are applied at session start but silently dropped when the app is relaunched through the standard activateApp. Users of dartVmServicePort would otherwise need to know they must switch to a different command (and hand-build the same flags) for every relaunch.

Happy to add a README note pointing real-device users to flutter:launchApp if that helps.

[KazuCocoa]

Thank you. Then, would https://appium.github.io/appium-xcuitest-driver/latest/reference/execute-methods/#mobile-launchapp help then?
To pass arguments, mobile: launchApp is more appropriate rather than acivate app.

appium-flutter-driver/driver/lib/driver.ts

Line 238 in e13a971

public async executeCommand(cmd: string, ...args: [string, [{skipAttachObservatoryUrl: string; any: any}]]) {

[masaaki-hori]

That makes sense — thanks for the pointer. I've reworked the PR along those lines: activateApp is left as it was, and mobile: launchApp now goes through the same cross-context path as mobile: activateApp (proxied to XCUITest from any context, then reConnectFlutterDriver, honoring skipAttachObservatoryUrl). Without that, it isn't usable here: in the FLUTTER context it ends up as Command not supported, and from NATIVE_APP the app relaunches but the Dart VM socket keeps pointing at the old process. I also documented relaunching with the dartVmServicePort flags via mobile: launchApp in the README.