# DartNative wants Flutter developers to ship native UI from Dart

> DartNative is a new commercial framework that renders Dart widgets as UIKit and Android Views instead of Flutter's canvas. This review covers its claims, compatibility limits and adoption risks.

- Author: Sailesh Dahal (https://saileshdahal.com.np)
- Published: 2026-09-08
- Reading time: 6 min
- Canonical: https://saileshdahal.com.np/dartnative-flutter-native-ui-framework
- Tags: Flutter, Dart, Mobile Development

---

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.

```text
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`](https://pub.dev/packages/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:

- [DartNative public repository and README](https://github.com/DartNative/dartnative)
- [DartNative architecture](https://github.com/DartNative/dartnative/blob/main/docs/architecture.md)
- [DartNative widget reference](https://github.com/DartNative/dartnative/blob/main/docs/widgets.md)
- [Getting started with DartNative](https://github.com/DartNative/dartnative/blob/main/docs/getting_started.md)
- [Dependency compatibility](https://dartnative.com/docs/getting-started/dependencies/)
- [DartNative troubleshooting](https://dartnative.com/docs/troubleshooting/)
- [DartNative pricing](https://dartnative.com/)
- [DartNative changelog](https://github.com/DartNative/dartnative/blob/main/CHANGELOG.md)
- [DartNative licence](https://github.com/DartNative/dartnative/blob/main/LICENSE)

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.