How would you choose between Appium's Flutter drivers and the native drivers for a courier proof-of-delivery app?

## The three candidates Framing this as *which Flutter driver* is the first mistake. There are three viable strategies: 1. **The official `appium-flutter-driver`** — attaches to the app's Dart VM Service through the `ext.flutter.driver` extension, declares `key` and `css selector`, and requires Flutter's test package in the build, so the app cannot be released as-is. 2. **The community `appium-flutter-integration-driver`** — built on Flutter's `integration_test`, a different in-build harness with a different maintenance story. 3. **No Flutter driver at all** — Android's UiAutomator2 driver and the XCUITest driver on Apple platforms, driving the release artifact against identifiers the app sets via `SemanticsProperties.identifier`, which surface as `resource-id` on Android and `accessibilityIdentifier` on iOS. ## The decision that comes first Ask whether the artifact under test must be the artifact you ship. For a courier proof-of-delivery app the answer usually leans hard toward yes: the binary carries signature capture, location and customer addresses, and a failure at a doorstep has no retry. Both Flutter drivers put test-only code inside the build they automate, which means a green suite speaks about a variant. That is survivable when you say so explicitly and cover the difference with a separate check — and unacceptable when the Flutter-driver suite *is* the release gate. ## What the assertions actually need The honest question is what the tests read: - If they assert what a courier can see and touch — a job card is on screen, the signature pad accepts input, the delivered state persists — the semantics tree carries enough and a Flutter driver buys nothing you need. - If they reach into widget state that never surfaces to the platform, a Flutter driver's Dart-level access is the only thing that gets you there. - If most of what you want is really unit-level, the answer may be that it does not belong in an Appium suite at all. ## What the rest of the fleet already speaks A suite that already drives other apps with Android's UiAutomator2 driver and the XCUITest driver has a locator vocabulary, a page-object layer, a device pool and a triage habit. Adding a Flutter driver adds a second vocabulary — `key` instead of `id` or `accessibility id` — and a second class of failure to diagnose. The native path keeps one set of concepts across the whole fleet; choosing a Flutter driver should be a decision to fund a second stack, not an accident of whichever tutorial the team read first. How much of the courier flow even lives in Flutter belongs in this weighing. Camera capture, a map rendered as a platform view, a system permission prompt and an operating-system share sheet are not drawn by the Flutter engine, so a Flutter driver's own context does not see them and the native side has to answer anyway. ## Ownership and blast radius | Consideration | Official Flutter driver | Community integration driver | Native drivers over semantics | |---|---|---|---| | Runs the shipped artifact | no | no | yes | | Widget-internal access | yes | yes | no | | Extra build flavour | yes | yes | no | | Locator vocabulary | driver-specific | driver-specific | the fleet's existing one | | App-team work | import the test package | wire an `integration_test` harness | author identifiers | | Maintenance owner | the official driver | a community project | the two mainstream drivers | A release gate for a delivery fleet is a poor place to carry the maintenance risk of a niche driver, and a good place to carry a small, explicit contract with the app team about identifiers. ## How I would decide for this app - Default to the native path: authored `SemanticsProperties.identifier` values, the UiAutomator2 driver on Android with `appium:settings[disableIdLocatorAutocompletion]: true`, the XCUITest driver on Apple platforms via `accessibility id`. - Keep the release gate on the signed artifact, and validate Apple-platform locators against a non-English build so an empty identifier cannot hide behind a label match. - Carve out a narrow Flutter-driver lane only when a specific, named assertion needs Dart-level state — and run it on an instrumented flavour as a supplement, never as the gate. - Revisit when the app's Flutter surface changes: more platform views push further toward native, a deeply stateful Dart flow pulls the other way. ## What makes this a judgment question Every option is right for some team, and none of them is free. The failure is not picking wrong; it is picking silently — inheriting a Flutter driver because an example used one, then discovering at the worst moment that the pipeline has never once exercised the binary a courier installs.