Skip to content
Sailesh DahalAI Integration Consultant

DartNative wants Flutter developers to ship native UI from Dart

A close look at the renderer-free Flutter fork

By Sailesh Dahal, AI Integration Consultant6 min readView as Markdown

DartNative has a pitch Flutter developers will immediately understand: keep Dart, keep stateful widgets and hot reload, but stop drawing a fake TextField on a canvas. Use the real one. Text, inputs, lists and navigation become UIKit or Android Views, so an iPhone control behaves like one and an Android control does not have to pretend otherwise.

That is more interesting than the usual cross-platform performance claim. Flutter has always made a deliberate trade. It draws almost every pixel itself, which gives you a consistent application on iOS and Android. It also means text selection, scrolling, keyboard behaviour and accessibility are Flutter’s job to reproduce. DartNative gives that work back to the operating system.

I like the premise. I would not migrate a Flutter application to it yet.

DartNative removes the renderer, not the hard parts

DartNative says it runs on Zero, a fork of flutter_zero with Flutter’s rendering stack taken out. Dart AOT and familiar Flutter tooling remain. Its dn command wraps the tooling, then DartNative turns the Dart widget tree into UIKit or Android Views through FFI. Android crosses JNI as well.

Dart widget and state tree
  -> DartNative reconciler
  -> FFI bindings (and JNI on Android)
  -> UIKit or Android View tree
  -> the operating system compositor

Yoga handles flexbox-style layout. When setState() runs, DartNative says it diffs the native view tree on the platform’s main thread. For long lists it has separate FastList, FastGrid and MasonryFastGrid widgets backed by the platform’s recycling controls. The ordinary ListView is for smaller collections.

That makes sense. A native UITextField and an Android EditText carry more than a rectangle and a cursor. They carry years of keyboard, selection, accessibility and input-method behaviour that cross-platform frameworks spend years chasing. DartNative can take that behaviour for free because the platform already owns it.

It also gives something up. Flutter can make iOS and Android nearly indistinguishable. DartNative wants the platforms to look and act like themselves. If your product depends on one precise visual language, that is a design decision, not a technical footnote.

The company claims AOT code from the first frame, no renderer warm-up and 120fps native scrolling. I could not find a public benchmark suite that runs the same app against current Flutter on representative devices. The demos show DartNative working. They do not prove that it wins on your application. That is still a benchmark you have to run yourself.

The package question will decide most migrations

The documentation makes migration look pleasantly small at first. Change an import to package:dartnative/flutter_compat.dart, keep using Column, Row, Container, Text, ListView, Navigator and setState, then carry on.

That works only while the code stays inside the part DartNative reimplemented. DartNative is Flutter-compatible, but it does not run the Flutter framework. Pure-Dart packages can work when they do not import package:flutter. Flutter packages that rely on Flutter APIs, MethodChannel or flutter_web_plugins need a DartNative plugin or an FFI/JNI port. The troubleshooting guide names go_router as unavailable because flutter_web_plugins is not there.

The same limit appears in widgets. TabBar, TabBarView and Dismissible are currently unsupported. Some parameters are omitted or renamed. DartNative says incompatible code fails at compile time instead of quietly changing behaviour, which is the right choice. It still means the migration starts with a package and widget audit, not a global find-and-replace.

I would inventory the application before trying it: third-party Flutter packages, custom painters, platform channels, web and desktop targets, anything that needs identical pixels across phones. The number you get from that inventory is more useful than the number of familiar widget names in the docs.

The harder risk is the company behind it

DartNative calls iOS and Android production-ready and names Gee and Presence Messenger as production users. Its public changelog also calls 31 July 2026 the first public preview and says some pieces will change before 1.0. That does not mean the product is unsafe. It does mean the framework has not had Flutter’s years of public bug reports, patches and strange edge cases.

The core framework is proprietary. The public GitHub repository has documentation, examples, demos and issues. The company develops the framework in private repositories and distributes compiled artifacts.

The official demos are free. Your own application is not. DartNative’s Community plan costs $29 a year and permits one production app, defined as an app past 1,000 installs. Standard is $49 a year for unlimited apps, and Pro is $99 a year with higher-priority support. All three include the framework and the vendor’s first-party plugins. You also need a device licence key to build and ship. If the subscription ends, the licence says apps already in users’ hands keep running, but you cannot make new builds or deployments.

There is a source-release promise in the licence. If a defined discontinuation event happens, DartNative says it will release the source under BSD-3 within 90 days. I would take that as a contingency, not an answer to the ordinary question every mobile team eventually asks: who fixes the framework when we hit an urgent bug on a Friday?

One easy mistake is to confuse it with the older open-source dart_native package. That package is a bridge for calling Objective-C, Swift and Java from Dart. This DartNative is a different product with a separate toolchain, licence and maintenance story.

What I would do with it

I would give DartNative one ugly screen, not an entire application. Pick the screen with the long interactive list, stubborn text entry, keyboard transitions, deep navigation and accessibility requirements. Add analytics and crash reporting. Build it for both platforms, then measure startup, scrolling and input on the devices your users have.

Then count what you had to replace. The missing package or native integration is usually more expensive than the widget you can see on screen.

Teams whose product lives on iOS and Android, whose Flutter dependency list is short, and whose hardest problems are text input or platform behaviour should try it. Teams that need Flutter’s package community, web, desktop, canvas-style interfaces or source-level control should stay put. DartNative may earn its place. It needs to earn it against your awkward screens and your dependency list, not against a polished demo.

Sources

Primary:

The architecture, supported widgets, claimed production use and performance framing above come from DartNative’s own documentation. I have not independently benchmarked the framework or audited its private source code.