Or Tauri, or Flutter, or Electron. Each solves part of this, and each gives something up to do it. Here is what they trade, and what WAID trades instead.
Every one of these is a good tool with production users. The problems below are structural - consequences of the architecture, not things a future release fixes. Where WAID gives something up, that is on this page too.
at a glance
Architecture comparison
WAID compared with React Native, Tauri, Flutter and Electron across 11 architectural properties.
capability
WAID
React Native
Tauri
Flutter
Electron
Write it in React and TypeScriptThe language and component model your team already has.
Yes: React + TSReact + TS
Yes: React + TSReact + TS
Yes: any web stackany web stack
No: Dart + widgetsDart + widgets
Yes: any web stackany web stack
Ships the Vite and Tailwind dist you already buildNo second toolchain, no port of your design system.
Yes: packages your distpackages your dist
No: Metro, RN stylingMetro, RN styling
Yes: loads your distloads your dist
No: Dart toolchainDart toolchain
Yes: loads your distloads your dist
One renderer you control on every targetNobody else’s widget set and nobody else’s browser in the loop.
Yes: detir-scene, wgpudetir-scene, wgpu
No: OS widget treesOS widget trees
No: system webviewsystem webview
Yes: ImpellerImpeller
No: bundled Chromiumbundled Chromium
Identical pixels across platformsOne mockup can be the source of truth for every target.
Yes: one rendererone renderer
No: iOS ≠ AndroidiOS ≠ Android
Partial: three enginesthree engines
Yes: one rendererone renderer
Partial: desktop onlydesktop only
No platform branching in app codeNo Platform.OS forks accumulating as the app gets serious.
Yes: one treeone tree
No: Platform.OSPlatform.OS
Partial: per-webview quirksper-webview quirks
Yes: one widget treeone widget tree
Yes: one engineone engine
iOS and AndroidBoth mobile platforms as first-class build targets.
Yes: .ipa and .apk.ipa and .apk
Yes: its home groundits home ground
Partial: newer, since v2newer, since v2
Yes: first-classfirst-class
No: not addressednot addressed
macOS, Windows and LinuxDesktop artifacts from the same source.
Yes: one target flagone target flag
Partial: out-of-tree forksout-of-tree forks
Yes: its home groundits home ground
Yes: first-classfirst-class
Yes: its home groundits home ground
A real web target: DOM, SEO, DevToolsThe web build is an ordinary website, not an app in a canvas.
Yes: the dist is a sitethe dist is a site
Partial: RN-Web, separateRN-Web, separate
Yes: it is a web appit is a web app
No: canvas, no SEOcanvas, no SEO
Yes: it is a web appit is a web app
No browser bundled with each appNothing for you to ship, patch, and keep patched for its lifetime.
Yes: a runtime, not a browsera runtime, not a browser
Yes: native viewsnative views
Yes: uses the OS webviewuses the OS webview
Yes: own rendererown renderer
No: Chromium per appChromium per app
App actions callable by agents over MCPSemantic calls like purchase_order.create, not UI automation.
Yes: waid app scanwaid app scan
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
App-to-app and agent relay in the runtimeA tool in one app can invoke an action in another.
Yes: the detir relaythe detir relay
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
No: build it yourselfbuild it yourself
the architecture gives you this
possible, with a caveat that bites
not in the model
row by row
How each mark was decided
React Native
Maps JSX to native UIKit components on iOS and native Views on Android.
React Native gives you React with two platforms underneath. WAID gives you React with one renderer underneath.
You do not get identical output
A TextInput looks and behaves differently across platforms; a ScrollView has different momentum physics. One mockup cannot be the source of truth, so you ship two designs whether you wanted to or not.
The platform checks never go away
Serious apps fill with Platform.OS branches. “Write once, run anywhere” is closer to “write 80% once, write 20% twice”.
The bridge is the performance ceiling
Animation, scroll under load and complex gestures are bounded by the JS-to-native handoff. JSI reduces the cost; it does not remove the boundary.
No real web target
RN-Web is a separate pipeline with its own gotchas. One source shipping to mobile and web is not what you get.
Tauri
Runs your web app inside the operating system’s WebView in a native window.
Tauri ships your app inside three different browsers. WAID ships one runtime that draws the pixels itself.
WebView fragmentation is browser fragmentation
WKWebView is Safari, WebView2 is Chromium, WebKitGTK is something else. You fight the same engine divergences as on the web, plus each one’s embedding quirks.
No control of the GPU
You get CSS animation and canvas. No shaders, no custom rendering, no high-frame-rate visualisation beyond what the WebView allows.
Native feel is approximated
Touch behaviour, scroll momentum and keyboard handling are subtly off, and the JS workarounds can regress with an OS update you do not control.
Flutter
Brings its own GPU renderer (Skia, now Impeller) and its own widget model, in Dart.
Flutter’s web is a canvas pretending to be a website. WAID’s web is a website - the same source ships both.
Dart, not TypeScript
A smaller ecosystem, and a smaller pool of developers. It also matters for agents: models write TypeScript and React fluently because that is what they were trained on.
A widget tree, not React
Composition has to be relearned. The largest pool of front-end developers already thinks in React.
The web target is a compromise by design
HTML renderer: awkward output and accessibility gaps. CanvasKit: pixel-accurate, but a multi-megabyte WASM download, the whole app as one canvas, no real DOM, no SEO, broken text selection and find-on-page, and screen readers struggling.
Electron
Bundles a full Chromium with every application.
Electron ships a browser with every app. WAID ships one runtime and the dist you already built.
A browser per app
Hundreds of megabytes on disk and at idle. Defensible for an IDE; hard to justify for an ordinary app.
Desktop only
It does not address iOS or Android at all, so it is not a cross-platform answer.
You own the patch treadmill
The bundled engine is yours to keep patched for the life of the app.
the trade
Where WAID is the wrong choice.
Three cases where you should use something else. We would rather you found this here than three months in.
You only ship iOS, and want platform-perfect iOS
Use SwiftUI. WAID’s value is one codebase across platforms; without that constraint, native is better.
You need deep platform integration
AR, complex camera pipelines, system extensions. The escape hatches do not cover these yet - use native, or React Native with custom modules.
Your team already ships RN or Flutter happily
Switching cost dominates the structural argument. WAID is for new builds, and for teams whose pain is acute enough to justify the move.
Still think WAID fits?
We’re onboarding a small group of design partners building cross-platform, agent-native apps.
