跪拜 Guibai
← All articles
Flutter · Android · Frontend

DartNative Swaps Flutter's Rendering Engine for UIKit and Android Views

By 恋猫de小郭 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

DartNative surfaces a real pain point: Flutter's rendering abstraction still introduces frame-level lag in interactions like keyboard avoidance and video transitions. A framework that compiles Dart to native views offers a concrete benchmark for what Flutter itself leaves on the table.

Summary

A new project called DartNative compiles Dart code directly to native rendering, using UIKit on iOS and Android Views on Android instead of Flutter's Skia-based engine. It claims zero abstraction layers and no bridge, positioning itself as a direct-to-native alternative for developers who want to keep writing Dart but are unhappy with Flutter's rendering performance.

The framework's pitch centers on scenario-specific optimizations that are hard to achieve in Flutter. Keyboard animations sync with the system's Core Animation transaction on iOS and WindowInsetsAnimation on Android, shaving frames off the typical Flutter keyboard experience. Long lists, video playback, and WebView all receive similar native-level tuning, including a video player with built-in pre-caching for zero-delay transitions.

Despite the technical ambition, the plugin ecosystem is thin — only 34 first-party plugins exist — making migration from Flutter painful. The project appears aimed at a narrow slice of Flutter developers frustrated with specific interaction bottlenecks, but the author notes that even the community fork Flocker has already adopted more modern rendering paths like Graphite.

Takeaways
DartNative compiles Dart code to run directly on UIKit and Android Views, bypassing Flutter's engine with zero bridge and zero abstraction layers.
Keyboard animations hook into iOS Core Animation transactions and Android WindowInsetsAnimation, claiming a few frames of improvement over Flutter.
Long lists, video playback, and WebView get scenario-specific native optimizations; the video player includes pre-caching for seamless transitions.
CustomPaint is preserved as a Skia Graphite island, allowing shader-heavy elements to render through Skia while the rest of the UI uses native views.
Only 34 first-party plugins are available, covering basics like camera, maps, and auth, but the ecosystem is far too small for broad adoption.
The Flutter community fork Flocker has already adopted Graphite and WebGPU-based texture rendering, making DartNative's approach look dated.
Conclusions

Launching a new cross-platform framework in 2026 to siphon off Flutter users is an odd bet — the window for framework fragmentation closed years ago, and the plugin gap alone makes migration a non-starter for most teams.

DartNative's real value isn't as a Flutter replacement but as a stress test: it demonstrates exactly which interactions Flutter's engine still can't handle natively, and those gaps are measurable in frames.

The project's existence suggests a small but persistent group of Dart developers would rather switch rendering backends than abandon the language, which says more about Dart's stickiness than Flutter's weaknesses.

Concepts & terms
Skia Graphite island
A rendering technique where most of the UI uses native platform views, but a specific region — such as a shader-heavy animation — is rendered by Skia's Graphite backend, giving developers native performance with access to custom paint operations.
WindowInsetsAnimation
An Android API that allows views to react to system window inset changes — like the keyboard appearing — in sync with the system's animation frame callback, enabling smooth, jitter-free keyboard transitions.
Core Animation transaction
Apple's mechanism for grouping layer changes into a single render pass; joining the keyboard's transaction means UI updates happen in the same frame as the keyboard animation, eliminating desynchronization.
From the discussion

The discussion centers on DartNative's practical role. One view holds that full replacement of Flutter is unrealistic, but the framework could shine as a drop-in fix for Platform View's notorious Android overhead. A separate question asks whether the earlier Flocker project has already been abandoned, and a final remark attributes the entire shift to AI taking over development work.

Full Flutter replacement is impractical; DartNative's real value lies in supplementing Flutter, specifically by replacing the high-overhead Platform View on Android.
Flocker, a prior attempt in this space, may already be dead.
The emergence of AI-driven development renders such framework-level innovations less relevant.
Featured comments
taosimple 1 likes

Replacing Flutter isn't very realistic, but it would be nice as a supplement to Flutter. If this approach could replace Flutter's Platform View, that would be great — the overhead of Platform View is still quite noticeable, especially on Android.

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗