How can Appium drive a release Flutter build on Android and iOS with no Flutter driver?

## The gap this closes Appium's official Flutter driver attaches to a Dart VM Service that only a build carrying Flutter's test package publishes, so it cannot drive the artifact you actually ship. The community `appium-flutter-integration-driver` builds on Flutter's `integration_test`, which is a different in-build harness rather than none. Both leave the same question open: how do you automate the signed courier proof-of-delivery build that drivers install? The answer is to stop using a Flutter driver and let each platform see the widgets. ## What a release Flutter build exposes to the platform Flutter publishes a semantics tree to its host platform for accessibility. Among its properties is an identifier — `SemanticsProperties.identifier` — and Flutter maps it onto the field each platform's automation already reads: - On **Android** it surfaces as `resource-id`, the attribute Android's UiAutomator2 driver matches with the `id` strategy. - On **iOS** it surfaces as `accessibilityIdentifier`, which the XCUITest driver reads behind its `name` attribute and matches with `accessibility id`. Write the shape, not a release number: confirm that the Flutter release your app is built on exposes the identifier field before you build a strategy on it. ## Android: the package-prefix trap Android's `id` strategy expects a package-qualified `resource-id`, and the UiAutomator2 driver helpfully completes a bare id with the app's package name. A Flutter semantics identifier is not package-qualified, so that autocompletion makes the locator miss. Turn it off for the session: - Send `appium:settings[disableIdLocatorAutocompletion]: true`. - Then an `id` locator matches the identifier string exactly as the Flutter widget declared it. ## Apple platforms: the fallback that bites On Apple platforms the XCUITest driver resolves `name` to the element's `accessibilityIdentifier` **or, when that is empty, to its label**. So a widget with no identifier set does not fail loudly — it quietly matches a visible, localised label instead. A courier app shipped in several languages then passes in one build and fails in another for reasons that look like flake. The defence is to set the identifier on every widget the suite touches, and to treat a locator that works only in one language as an unset identifier rather than a timing bug. Android fails in a different key, and a kinder one. A missing identifier there falls back to nothing at all, so the `id` locator simply matches no element and the run breaks loudly on the first attempt rather than passing for months in one locale and failing in the next. ## The two paths side by side | | Official Flutter driver | UiAutomator2 and XCUITest over semantics | |---|---|---| | Build under test | test-instrumented only | the signed release artifact | | Channel | the Dart VM Service, over a WebSocket | each platform's own automation stack | | Locators | `key`, `css selector` | Android `id`; Apple platforms `accessibility id` | | Sees widget internals | yes, in Dart | no — only what semantics publishes | | Extra app work | import the test package | author identifiers on the widgets | ## What you give up, honestly - No Dart-level state: you assert what is rendered and reachable, not what a widget holds internally. - No `key` strategy: the keys the app's own widget tests use do not travel to a native driver. - A widget with no identifier is effectively unaddressable on Android and dangerously label-matched on Apple platforms. - No `flutter:` execute methods: those belong to a Flutter driver's own session, not to a UiAutomator2 or an XCUITest one. - Anything never surfaced to the semantics tree — decorative canvas, custom painters without semantics — is invisible to both native drivers. ## A working order for the courier app 1. List the flows the suite must own end to end: sign in, accept a job, capture a signature, mark delivered. 2. Ask the app team to set `SemanticsProperties.identifier` on exactly the widgets those flows touch, with stable, non-localised strings. 3. Run Android with the UiAutomator2 driver and `appium:settings[disableIdLocatorAutocompletion]: true`, finding by `id`. 4. Run Apple platforms with the XCUITest driver, finding by `accessibility id`, and verify each locator against a non-English build so a label fallback cannot hide behind a passing run. 5. Keep one shared page-object layer, since both sides now match the same authored identifier string even though the underlying attribute differs per platform. That last point is the quiet payoff. Identifiers authored once in the widget tree give a cross-platform suite a single vocabulary, on the artifact you actually ship, with no Flutter-specific driver in the stack at all.