Tutorial · 10 min · intermediate

Port your Flutter app

Moving an existing app across, not just one screen. Keep your Flutter repository alongside the new one so nothing is locked in, port the state layer first, and write the plugins you are missing. We did it for Gee in two weeks.

You cannot mix Flutter and DartNative in one app. That sounds like a hard choice, but if you already have a Flutter app, it is not, because porting does not commit you to anything.

Keep your Flutter repository and add a DartNative one alongside it. The code is largely the same, so you can move between the two freely. You are not locked in either direction.

That is exactly what we did for Gee, the first DartNative app shipped, on the App Store and Google Play. We ran it for a month before adopting it in production. The port took two weeks.

DartNative makes your app premium, because the UI really is the platform’s own. It does not just look native, it behaves native: the scrolling, the gestures, the transitions and the text selection are the ones the system ships, not an imitation of them. What surprised us more was the stability: no flickering, and no crashes so far. It has been the steadier of the two.

Starting something new? Then none of this applies. Build it in DartNative and keep one repository, the way you would with any other framework. Two repositories are a safety net for an app that already exists and already has users, not a way of working.

1. Port the state layer first

Almost everything in your app hangs off state management, so start there and the rest follows.

DartNative has its own, and it is small. There is no ProviderScope and there are no base classes: setState for local state, signal and watch for shared stores, Provided for values scoped to a subtree.

This is mechanical work, so ask your LLM to do it. Point it at the state management guide and at the Starter app, then let it convert your stores. If you would rather learn it yourself first, State, from setState up covers the same material at a slower pace.

2. Port the screens

Most widgets come across unchanged. A few differ on purpose, and Porting a Flutter screen is the map of which is which.

3. Write the plugins you are missing

This is the part people expect to be blocked by, and it is usually the shortest. If a plugin you depend on does not exist yet, ask your LLM to write it, pointing it at:

Once your core plugins are in place, building in DartNative is as fast as Flutter. The plugins are the one-time cost, and you pay it once.

When to switch

Once the DartNative build can do everything the Flutter build can, ship it and keep the Flutter repository around for a while. We ran both side by side for a month, and there’s no benefit to deleting the fallback too early.

In fact, you may want to keep both indefinitely. As long as both are available, you can switch between them whenever you need to, so you’re never locked in.