This document outlines the released services and the development sequencing for planned ones in the WebdriverIO Desktop & Mobile Testing project.
Published packages, grouped by release maturity. Status reflects the npm dist-tag, not just "exists on npm".
@wdio/electron-service — v10.x
Platforms: Windows, macOS, Linux
@wdio/tauri-service — v1.x
Platforms: Windows, macOS, Linux
@wdio/dioxus-service — v1.x
Platforms: Windows, macOS, Linux ('embedded' provider); Windows only for 'external'
Highlights: Wry webview → CDP (shared patterns with the Tauri service); execute, mocking, log forwarding, browser mode, multiremote, standalone session.
Feature-complete services published on the
nextdist-tag while the API and CI stabilise toward1.0.
@wdio/react-native-service — v1.0.0-next
Platforms: Android, iOS
Highlights: native find/tap via Appium (UiAutomator2 / XCUITest); execute + mock via Hermes CDP (debug/Metro build); deeplink, context switching, log capture, multiremote/DeviceManager. Established the shared @wdio/native-mobile-core mobile scaffold.
@wdio/flutter-service — v1.0.0-next
Platforms: Android, iOS
Highlights: native find/tap via appium-flutter-driver (FLUTTER context); execute (a Dart expression) + mock (the cooperative wdio_flutter Dart contract) via the Dart VM Service (debug/profile build); deeplink, context switching, log capture, multiremote/DeviceManager. Built on @wdio/native-mobile-core.
Feature surface limited by upstream gaps; not yet at parity with the services above.
@wdio/electrobun-service — v0.1.x
Platforms: macOS 14+ (CEF), Windows 11+ (WebView2), Linux (WebKitGTK)
Highlights: drives three renderers — macOS via CEF (CDP), Windows via the native WebView2 (Chromium over CDP, no CEF), and Linux via the native WebKitGTK (W3C WebDriver, electrobun ≥ 2.0.1, single-window); Windows also runs the multi-window suite that CEF can't on CI.
Caveats: deeplink on Windows and deeplink/multiremote on the macOS CEF path are upstream-blocked (#320); macOS WKWebView has no automation surface, so a self-shipped embedded driver is deferred (#629). Each upstream fix re-enables a feature, graduating toward 1.0 at full parity. See the package README.
The roadmap above is scoped to new framework support. Capability-level features that apply to existing services are tracked here.
| Capability | Status | Notes |
|---|---|---|
| Visual regression testing | ✅ Available via @wdio/visual-service |
See docs/visual-testing.md for the wiring + provider notes. |
| Video recording | 🔍 Not yet planned | Treated as a separate track. Universally a debugging artefact rather than a regression signal in the test-frameworks we surveyed. |
The mobile services (React Native, Flutter, and future Capacitor) share a common Appium layer in @wdio/native-mobile-core. Two tracks harden and generalise it.
| Track | Status | Notes |
|---|---|---|
| Zero-config mobile setup | 📋 Planned | Chromedriver-style auto-management: opt-in Appium driver install + version matrix, per-worker realm-port allocation, cap-default derivation, and a fail-fast preflight doctor. Shared #378 + Flutter #405 + React Native #406. |
Generic @wdio/mobile-service |
📋 Planned | A publishable mobile service for any Appium-drivable app (plain native, NativeScript, MAUI, Capacitor shells): native find/tap, deeplink, context switching, logs, multiremote — without a framework realm. React Native and Flutter converge onto it as thin extensions that add only their JS/Dart execute/mock. Design: spec. |
Composition stays two-entry — services: ['appium', '<framework>']; the shared layer is inherited, not listed separately. See the design spec for the full model.
Sequencing: the zero-config setup-automation track is in flight now (pre-release hardening of the mobile services). The generic @wdio/mobile-service + the React Native / Flutter convergence onto it is targeted Q4 2026, ahead of Capacitor — Capacitor is its first consumer and extends it rather than re-implementing the mobile scaffold.
The table below quantifies the key factors used to prioritise and sequence planned services. GitHub stars serve as a proxy for ecosystem size and developer interest; automation driver maturity indicates how production-ready the underlying test infrastructure is; and pattern reuse scores how much existing service code can be directly leveraged. Stars are approximate as of early 2026.
| Framework | Type | GitHub Stars | Automation Driver | Driver Maturity | Pattern Reuse vs Existing Services | Key Dependencies | Relative Integration Complexity |
|---|---|---|---|---|---|---|---|
| Electron (released) | Desktop | ~120k | Chrome DevTools Protocol (CDP) | ✅ Proven | — | Chromium, Node.js | — |
| Tauri (released) | Desktop | ~100k | tauri-driver + CDP | ✅ Proven | — | Wry, Rust toolchain | — |
| Dioxus (released) | Desktop | ~34k | Wry webview → CDP (shared with Tauri) | ✅ Implemented | High — same Wry/CDP patterns as Tauri service | Wry maturity, Dioxus desktop stability | Low–Medium |
| React Native (released) | Mobile | ~121k | Appium (XCUITest / UiAutomator2) | ✅ Proven | Establishes mobile scaffold | Appium server stability, XCUITest / UiAutomator2 | Medium |
| Flutter (released) | Mobile | ~175k | Appium Flutter Driver | ✅ Production-ready | Reuses React Native mobile scaffold | Appium Flutter Driver maintenance, Dart VM | Medium |
| Electrobun (released) | Desktop | ~11.7k | Native CDP (port 9222 by convention) | 🟡 Emerging | Medium — CDP attach patterns from Electron service; no driver process | Bun runtime, system webviews, OOPIF (per-tab) target routing | Medium |
| Ionic / Capacitor | Mobile | ~52k / ~15k | Appium WebView context switching | ✅ Proven | Reuses mobile scaffold; pure WebView — zero new complexity | Appium server, native WebView availability | Low |
| Neutralino | Desktop | ~7.9k | System webview → CDP (devtools endpoint) | 🟡 Emerging | Medium — similar endpoint detection to Electron service | System webview (WebView2 / WebKitGTK) | Low |
| Dioxus Mobile | Mobile | (same repo) | Cargo Mobile 2 — experimental | 🔴 Early-stage | Reuses mobile scaffold + Dioxus desktop learnings | Cargo Mobile 2 maturity, platform bridge stability | High |
| React Native Desktop | Desktop | (same repo) | Less mature than mobile counterpart | 🟡 Emerging | Leverages React Native mobile experience | React Native Desktop renderer maturity | Medium–High |
Forward sequence, ordered by target window. Targets are aspirational (see the disclaimer at the end).
Priority: High — unlocks Capacitor and any native / other-framework app
Promote the shared @wdio/native-mobile-core layer into a concrete, publishable @wdio/mobile-service for any Appium-drivable app (plain native, NativeScript, MAUI, Capacitor shells), and converge React Native + Flutter onto it as thin extensions that add only their JS/Dart realm. See Shared Mobile Infrastructure and the design spec.
Priority: Medium — Ionic ecosystem coverage
Prerequisite: extends the generic @wdio/mobile-service base — Capacitor is its first consumer, not a re-implementation of the mobile scaffold.
Target Platforms: iOS, Android
Why Capacitor:
- Ionic's 1M+ app ecosystem
- Pure WebView pattern (zero new complexity)
- Replaces deprecated Cordova/PhoneGap
Technical approach:
- Standard Appium WebView context switching
- appPackage/appActivity capabilities
Priority: Low — Niche use case
Target Platforms: Windows, macOS, Linux
Why Neutralino:
- Extremely lightweight alternative to Electron
- JavaScript ecosystem alignment
- Web-based architecture
Technical approach:
- System webview automation via ChromeDriver CDP
neutralinojs --enable-inspectorlaunch integration- Electron service patterns (devtools endpoint detection)
- Standard WebdriverIO parallelization
Priority: Low — Experimental platform
Target Platforms: iOS, Android (experimental)
Why experimental:
- Dioxus mobile is early-stage
- Reuses established mobile scaffold
- Completes Rust ecosystem coverage
Priority: Low — Desktop expansion
Target Platforms: Windows, macOS, Linux
Why later:
- Less mature than React Native mobile
- Lower demand vs mobile priorities
- Leverages the React Native mobile experience
The following frameworks were evaluated and excluded from the roadmap:
| Framework | Reason |
|---|---|
| NW.js | Declining popularity, overlaps with Electron |
| Cordova / PhoneGap | Deprecated (2020), replaced by Capacitor |
| Qt / QML | Native rendering — no WebDriver fit |
| .NET MAUI | No dedicated service planned (native UI needs no framework-specific channel) — but native MAUI apps are drivable via the generic @wdio/mobile-service over Appium (UiAutomator2 / XCUITest); MAUI is also the generic service's E2E fixture (it dogfoods this exact use case — spike #508 confirmed Appium drivability + a cheap ~1.7 min Android CI toolchain) |
| Blazor | Standard web needs no service; Hybrid WebView context switching is unreliable only on Windows/WinAppDriver — on Android/iOS BlazorWebView/HybridWebView are standard android.webkit.WebView / WKWebView and are drivable with a Chromedriver-matched config (spike #508) |
| Wails | Go webview, no established automation patterns |
When prioritizing services, we consider:
- Market demand - User requests and ecosystem size
- Technical feasibility - Availability of drivers and tooling
- Maintenance burden - Ongoing support requirements
- Ecosystem maturity - Framework stability and community
- Platform coverage - Mobile vs desktop gaps
- Integration complexity - Development effort required
We welcome community input on the roadmap! To suggest changes:
- Open a GitHub Discussion
- Provide use case and demand evidence
- Suggest technical approach if known
- Indicate willingness to contribute
Roadmap priorities may shift based on:
- Community contributions
- Framework ecosystem changes
- Technical breakthroughs
- Market demand shifts
Timelines are estimates and subject to change based on:
- Maintainer availability
- Community contributions
- Technical challenges
- Framework ecosystem changes
All dates should be considered aspirational goals rather than commitments.