The best way to build mobile apps.

Real native apps, written in Dart. DartNative renders with the platform's own views — real text, scrolling, keyboard and liquid glass. No Impeller. No Skia. No bridge. No alien feeling.

0abstraction layers
120fpsnative scrolling
34first-party plugins
1language — Dart, both platforms

If you know Flutter

You already know DartNative.

Same widgets, same layout, same hot reload, same Dart. DartNative just renders them with the platform's real views instead of Impeller/Skia. The only change is the import.

chat.dart · Flutter
// just Flutter
import 'package:flutter/material.dart';

Widget build(BuildContext context) {
  return ListView(
    children: messages,   // drawn by Skia
  );
}
chat.dart · DartNative
// same widgets, real native
import 'package:dartnative/dartnative.dart';

Widget build(BuildContext context) {
  return ListView(
    children: messages,   // real UITableView + UILabel
  );
}

The keyboard test

Every framework reacts to the keyboard.
This one moves with it.

iOS animates the keyboard on the GPU compositor — continuous, sub-frame precise. Flutter can only react at vsync: always 1–2 frames behind, visibly jerky. React Native round-trips through JavaScript. DartNative joins the same Core Animation transaction as the keyboard itself. Every frame follows the exact system curve — no per-frame relayout — and drag-to-dismiss stays interactive, with native momentum.

Zero stutter. Zero lag. Zero per-frame CPU.

The input bar rides the exact system curve, committed in the same compositor transaction as the keyboard slide. Interactive dismiss, rubber-band scrolling, real UITableView / RecyclerView physics — the chat screen every cross-platform team gave up on.

  • Same-transaction Core Animation on iOS, WindowInsetsAnimation on Android — indistinguishable from native
  • Exact system curve, no per-frame relayout
  • Interactive drag-to-dismiss, native momentum
Zero stutter. Zero lag. Zero per-frame CPU.

Adaptive by construction

One codebase. Both souls.

The same AppBar.searchBar renders Apple's in-place search on iOS 26 — real Liquid Glass, the App Store choreography — and the genuine Material 3 search app bar on Android. Not a lowest common denominator. Both platforms, at their best, from one widget.

iOS 26 · real UISearchBar + Liquid Glass custody bar
Android · the real Material 3 SearchBar + SearchView

Cold start

Launches like a native app. Because it is one.

There's no rendering engine to warm up — no Impeller, no Skia — and no JavaScript engine to boot. A DartNative app is AOT-compiled machine code driving the platform's real views — from main() to first paint in milliseconds, and that first frame is already native: real UIKit on iOS, real Android views on Android.

  • No rendering-engine init — no Impeller or Skia to warm up
  • No JS bundle to parse, no runtime to boot
  • Dart AOT: full speed from the first frame, no JIT warmup

Scroll forever

10,000 rows. Native physics. Flat memory.

Lists are real UITableView / RecyclerView with the OS's own momentum and rubber-band feel. FastList windows content natively, so memory stays flat where holding every widget would blow past a gigabyte — smooth at 25 rows or 25,000.

  • Native momentum + rubber-band overscroll
  • OS-level row recycling, bounded memory
  • 120fps on ProMotion, measured per-vsync

Text & input

The hardest thing to fake. So we don't.

Text renders through UILabel + CoreText and platform text on Android — not a canvas re-implementation. Inputs are real UITextField / UITextView, so selection, the magnifier, the edit menu and emoji are the system's own — not an imitation. Your users see a native app.

  • CoreText rendering — system fonts, emoji, Dynamic Type
  • Native keyboard types, autocorrect & secure entry
  • Real selection, magnifier and system edit menu

Video, done right

Native players. Cache & precache built in.

Playback is a real AVPlayer / ExoPlayer surface — and the two features feed apps actually need are one config away: disk cache and precache, long requested on Flutter's video_player. Here it's VideoCacheConfig(useCache: true, preCacheSize: 400 * 1024). For feeds, stories and chat that means instant next-video and every byte downloaded once — smoother scrolling, smaller bandwidth bill.

Real AVPlayerLayer / ExoPlayer · overlay controls, fullscreen
Cache + precache · prewarmed next video, bytes fetched once

Camera

Smooth rotation. Fast shutter. Media saved at the right aspect and orientation.

The preview is the platform's own camera view — AVFoundation / CameraX — living in the view tree. Flutter drives the same native cameras, but composites their frames into its canvas as a texture and re-derives size and rotation in Dart; that seam is where the long-standing preview-stretch and rotated-capture issues live. With the native surface in charge, rotation stays smooth — no flicker, no micro-freeze — the shutter fires fast, and media saves at the right aspect ratio and orientation.

  • Smooth rotation — no flicker, no micro-freeze
  • Fast shutter, EXIF orientation correct every time
  • Tap-to-focus & pinch-to-zoom — native gestures, no per-frame FFI
  • 16:9 / 4:3 / 1:1, flash, flip, photo + video

Lottie

Airbnb's real Lottie engine.

Animations run on lottie-ios and lottie-android — composed by Core Animation and the Android view system. Flutter's is a pure-Dart port: your app parses the JSON, so first play can hitch unless you preload and cache. React Native wraps the same engines, but its community bridge has long-reported frame drops on complex animations.

  • The real lottie-ios / lottie-android — not a re-implementation
  • Asset, runtime JSON, or URL — with disk caching
  • Preload remote .json / .zip / .lottie — warmed before first display
  • Play, pause, seek, speed, loop — via LottieController

Skia

When you need high-density real-time graphics.

A few things have no native equivalent: SkSL runtime shaders, generative art, thousands of moving sprites. For those, DartNative gives you Skia Graphite — a canvas island inside the native view tree, never the app's renderer. Go see one running: the shader effects in Gee are DartNative Skia, available on the App Store and Google Play.

  • Skia Graphite — straight to Metal on iOS, Vulkan on Android
  • Custom fragment shaders, distortion, animated per-pixel gradients
  • High-density real-time 2D — sprite- and shader-heavy games
  • Opt-in: add the package only when a screen needs it

Native canvas

Most drawing never needs Skia.

Shapes, paths, charts, diagrams — CustomPaint draws them with Core Graphics on iOS and android.graphics.Canvas on Android. The platform renders it and composites it with your other views, so it costs less per frame than a Skia surface and nothing at all in binary size.

  • The platform's own 2D — Core Graphics / android.graphics.Canvas
  • Zero binary cost — nothing extra compiled into your app
  • Paths, fills, clipping and text — charts and graphs included
  • Blur, gradients and animation have native backends too

When it breaks on a tester's phone

The log that survives TestFlight.

Dart, Swift and Kotlin share one log stream — in your terminal while you develop, no second console in Xcode. And with saveToFile: true, every launch persists its session to the device with production-safe rotation — so a release build that dies before its first frame, with no debugger and no crash report, still tells you where.

  • Native callbacks log next to your Dart — one interleaved stream
  • One self-capping session file — ~2 MB max, safe to ship
  • Boot breadcrumbs turn a frozen splash into a named suspect

Read the logging docs →

session.log · pulled from a TestFlight install
// one session file, appended each launch — Dart + native interleaved
session log: …/tmp/dartnative_session.log
=== dartnative session 2026-07-02 09:14:22 ===
[boot] plugins registered
[boot] skia + fonts registered
[boot] config loaded
// log ends here — the next boot step is the bug,
// found with no debugger attached.

The work behind it

Where DartNative stands today.

Half a million lines of original code, already used in production — with 34 first-party plugins, all free, every one backed by the platform's own APIs.

527klines of original code
3,900commits
40repositories
100%of plugins always free

Counts are original code only — generated and imported code excluded.

Used in production

Gee a voice-first AI companion App Store Google Play
Presence Messenger porting to DartNative App Store Google Play

The honest table

Why teams switch.

Cross-platform always traded fidelity and performance for reach. DartNative removes the trade.

DartNative Flutter React Native
Rendering   Real UIKit & Android views Impeller/Skia canvas Native views, driven from JS
Raw performance   — compute-heavy work trails AOT Dart
App performance   — sporadic jank can dent perceived performance — smooth when carefully optimized
Platform fidelity   — not quite native: text, emoji, input, selection, magnifier, tap feedback, transitions, scroll feel, system components — native views, but choreography from JS — keyboard sync and under-load motion can trail
Keyboard animation   Compositor-synced — zero stutter 1–2 frames behind, relayouts per frame Stock trails; keyboard-controller gets close — per-frame, not compositor-synced
Cold start   AOT — no engine, no JS runtime to boot Engine spin-up before first frame JS runtime boot + bundle load
Text   Real UILabel / TextView — the platform's own text engine, iOS and Android Canvas-drawn re-implementation — glyph weight, spacing, emoji and selection read off next to native UI Native text views, but updates come from JS
iOS 26 Liquid Glass   Real UIGlassEffect, day one Glass via platform views — can't wrap widgets, merge, or reach the native bar behaviors Real glass & native tab bar via Expo wrappers
Material 3 on Android   The real MDC components Faithful re-draw on its own canvas — not the MDC components Community re-implementations
Long lists   UITableView / RecyclerView windowing Memory stays flat, but rows rebuild instead of recycling — jank on fast flings FlatList virtualizes in JS; Shopify's FlashList adds JS-side recycling
Media (video & camera)   First-party players & camera — cache, precache, correct rotation No player cache; camera preview via texture, long-standing open issues Community-maintained (react-native-video, VisionCamera)
Lottie   First-party, on the native lottie-ios / lottie-android engines Community pure-Dart port — compositions parse in Dart, so apps preload & cache to hide the delay Community wrapper over the native engines — long-reported frame drops on complex and multi-animation screens
Debug logging   Dart + native, one stream — saved on device iOS native logs unreliable outside Xcode Two consoles: JS logs in DevTools, native logs in Xcode / logcat
Language   Dart Dart JavaScript / TypeScript
Ecosystem   Product-grade core + open community, all free Official + community packages Community packages
Support   — enterprise grade — we own your bug until it's fixed — open-source grade — nobody owns your bug: it can wait months, or forever — open-source grade — nobody owns your bug: it can wait months, or forever

A maintained ecosystem

Powerful plugins, maintained like a product.

First-party, native-backed, free — the essentials of app development, from camera and video to on-device AI. The community builds the rest, open source.

Contributors pay less.

Build the plugin you need. Open source, published in one command. The authors of popular plugins are considered contributors and pay half price for their Standard or Pro subscription — or nothing at all, based on plugin adoption. Every version you publish stays archived on dartpub.dev, so a dependency can never disappear.

Become a Contributor

dartpub.dev

The developer hub.

dartpub.dev is where DartNative lives: your account and subscription, the first-party plugins, and everything the community publishes — every version archived, so a dependency can never disappear. Pure-Dart packages from pub.dev are supported too: if it doesn't import package:flutter, add it to pubspec.yaml as usual.

  • First-party and community plugins, one registry
  • Pure-Dart packages from pub.dev — no fork, no patch, no wrapper
  • Publish your own with one command — pure Dart needs no native build
  • Production adoption discounts your subscription, the more it's used

Publish on dartpub.dev

pubspec.yaml · Gee, shipping on the App Store
dependencies:
  # the native surface — from dartpub.dev
  dartnative_supabase: ^0.1.0
  dartnative_revenuecat: ^0.1.0
  dartnative_notifications: ^0.1.0

  # pure Dart — straight from pub.dev, unchanged
  dio: ^5.7.0
  http: ^1.2.2
  uuid: ^4.5.1
  intl: ^0.20.2
  crypto: ^3.0.3

Pricing

Start building for free.

Try it free with our demos and getting-started guide — no account or licence required. To build your own, pick a plan. Community lets you build your first app for free. Standard and Pro are for more demanding projects, with priority support, unlimited apps, and CodePush. Apps you've already shipped keep working for your users, even if you stop paying.

A production app is one that has passed 1,000 installs — build and test as many apps as you like. Support runs through our public GitHub repo, where Pro issues are answered first, then Standard, then Community.

* CodePush is in testing and not yet available. When it ships, your plan includes its allowance at no extra cost.

Why it's different

Here, you're the customer.

Free frameworks have a hidden cost: you're not the customer. When something breaks at the engine or framework level, no one's paycheck depends on fixing it — and no volunteer can. You deserve a framework that treats your bug as its problem.

The hard bugs live at the engine and framework level — not in your app.

Keyboard sync, text fidelity, video caching, and a hundred other low-level details need sustained, full-time specialists. Flutter's own video_player still has no network caching — a fix has waited years. Not because anyone is lazy — because nobody has to prioritize it.

A company builds the engine and framework. The community builds plugins.

That's the honest division of labor. The engine and framework are on us. Developers use them — or write plugins, where domain expertise wins. And adoption pays the author back — a discount that grows with how much the plugin is used.

The sunset clause.

“Closed source” shouldn't mean “trust us.” Our license binds us — and any future owner: if DartNative is ever discontinued, the framework and its first-party plugins are released publicly under BSD-3. Worst case? DartNative becomes open source. Read the continuity guarantee →

Your shipped apps never stop working.

Even if you stop paying. If your subscription lapses, apps you already shipped keep working for their users — existing installs and new ones. A lapse only pauses you: building and shipping stop until you renew. Punishing your users for your billing state is something we just don't do. It's in the license →

Start building native, in Dart.

It's the framework you know, rendering the views your users expect.