What happened​

In 2020 Shopify bet on React Native: one codebase, lower costs. In January 2025 its head of mobile wrote that the future of React Native was bright. On 10 September 2026 the same person published Native is now the future of mobile at Shopify. The Shop app is already rebuilt and in the stores; the main Shopify app — more than 300 screens, widgets, an Apple Watch app, Siri Shortcuts — ships later this year.

They do not say React Native was a mistake. They say it was the right choice in 2020 and the conditions have changed.

What native gave them​

From the Shop app migration post:

Six core engineers, twelve weeks from proof of concept to the stores. The proof of concept itself took one engineer one week.

The advantages of native were always known. They just always looked small — a slightly faster start, a slightly smaller build, a few fewer platform bugs — next to the cost of building everything twice.

Why now​

Keeping two codebases used to mean keeping two full development teams. Now agents write most of the code, and they can also take on the supporting work: checking that a feature behaves the same on both platforms, comparing, verifying. Shopify puts it this way:

Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer the deciding factor it was in 2020.

The same thing is happening everywhere. With agents you can port almost any library to your own stack, or rewrite a whole framework, and do it fast. That shifts what counts as a good or a bad technical decision.

How they did it​

The interesting part is not the decision but how you trust a rewrite of this size to agents at a company where any mistake costs real money. They did not just tell a model to rewrite the app. They built a pipeline.

Logic separated from UI. Business logic was split from the interface so cleanly that it runs headless, on a desktop machine. Agents tested it through a CLI and console tests — inspect the app's state, navigate, perform actions — in milliseconds, without starting an emulator. The UI was verified separately: the new screens were compared by screenshot against the running React Native app at the same checkpoints. Their tool for this, Tardis, also captured analytics events in both apps so agents could compare event names, counts and payloads.

Small checkpoints. Their system, Helix, cuts a screen into small ordered slices that can be reviewed in minutes. Each slice has to prove its behaviour with tests, match the running app in a visual review, survive two adversarial code reviewers and get a human's approval before it is committed. Review feedback is remembered, so the loop needs less help as the migration goes on.

Where agents fell short. Even inside that pipeline, the generated code brought duplication, architectural drift and performance problems. Shopify is explicit that native expertise remained essential — this only worked because they had a team of native experts reviewing it.

What the numbers leave out​

A few things did not fit into the video:

• The comparison is against the old React Native architecture. Commenters pointed out that nobody knows how the New Architecture would have measured — and moving to it was a large refactor Shopify faced anyway.
• It was a port, not a new product. Agents had a working app to read and to compare against. Shopify says agents worked best exactly when they had an existing implementation; building something new does not speed up the same way.
• Two platforms is now permanent. Feature parity "at all times", two reviews, two releases — and no over-the-air updates past the store.

Should Flutter developers worry?​

I do not think so — I am quite sure not.

This is one more example of agents making a little more possible. The biggest tech companies always ran native, with parallel teams for each platform, and never went cross-platform. Shopify is a large company, but not that large; agents let it work to the standards of companies with stronger development teams. It is the same shift as a small business now being able to build its own app, which used to take a mid-sized one. The cost of reaching the same result drops, at every level.

And rewriting is a pain in any case. For most companies it simply is not worth it: it is far better to put the effort into the product — new features, higher quality — than to chase the last 1% of bugs or shave megabytes off a build. The gains Shopify got matter much less to most teams.

So I do not expect this to move the job market much, and Flutter even less. In my view Flutter is well ahead of React Native, so it suffers less from trends like this one.

What I do take from it is the same lesson that changed my own work: I recently rewrote my framework quite radically, precisely because I came to trust agents with very large tasks done in short time. Is anyone around you talking about moving from one stack to another with agents?

The video version, in Russian, is on YouTube.

We connected it to Claude Code on a demo app and checked what it gives in practice.

Connecting it​

One command:

claude mcp add --transport stdio dart -- dart mcp-server --enable all

Without --enable all, half of the tools are switched off. Under the hood it goes through the Dart Tooling Daemon — the same thing DevTools uses for debugging. The next agent session starts the server and receives the list of tools.

What the agent could already do​

The analyzer, tests, dart fix, formatting, searching pub.dev. All useful, and all things an agent does without the server — through the terminal and the web. In the demo it went to search pub.dev through the tool; it would have found the package just as well without it.

What is actually new: the running app​

This is the part worth having:

• runtime errors from the live app, straight to the agent;
• the widget tree, as the app has it right now;
• taps and text input through Flutter Driver — tap, enter text, wait, get an offset, take a screenshot;
• evaluating an expression inside the running app — the agent can print a value on the spot instead of finding the place in the code and adding a print;
• hot reload after a fix.

In the demo the agent pulled the runtime errors, found a layout overflow, fixed it and hot-reloaded — without being shown where the problem was. Without MCP it could not have seen those offsets and would have been guessing.

The obvious use is the one that scales. You have built a large app and want every screen checked. Normally you find each overflow by eye, then describe it: "in this widget, overflow". With the server the agent walks the screens itself and collects the layout errors. Or you click through yourself and the agent gathers the errors through MCP.

What it costs​

The descriptions of all 24 tools land in the context of every session and are reread on every step of the agent. A task takes anywhere from twenty to a few hundred steps, and every one of them carries the whole list — cached, but still read, and still sitting in the context the agent has to reason within.

Verdict​

For a tool that matters on the occasional layout bug, that price is paid all the time. So in DartWay it will not be on by default. We will add it to the framework as an on-demand tool — connected for a run of visual scenarios or for fixing layout bugs, and not present in everyday development sessions. Keeping it in every session is overkill.

The video version, in Russian, is on YouTube.

The lens matters, so it goes first. Most of our development no longer happens in front of a running app. One session holds the conversation about the work; it starts separate agent sessions for development and for code review; several tasks run at once, in the background; and the result gets looked at on a test server a couple of times a day. Several of Serverpod 4's headline features are built for a different picture — a developer at a desk with the whole stack running locally.

Full-stack hot reload​

The database, the server and the Flutter app come up with one command. An edit anywhere — from a model to a screen — is picked up live, code generation included, and the app keeps its state. No more four terminals and restarting things by hand.

Worth it? Convenient, and it barely touches how we work. With agents running in parallel there is often no local stack up at all: changes go to a test server and are checked there, and in most cases that is enough. Bringing a stack up was never the hard part.

Postgres without Docker, and an MCP server​

For local development there is now a built-in Postgres, so Docker is optional. And the running app exposes an MCP server: your coding agent can reach into the live stack — logs, migrations, the running Flutter app.

Worth it? Useful on the occasional tricky bug. It does not solve a problem we actually have: the agent already sees the logs, and in practice it rarely lacks information to work out what is going on. (We looked at the same idea in Dart's own MCP server — a separate post.)

Offline and a database on the client​

The same models and ORM now generate SQLite in Flutter, and a single line — database: sync — turns on two-way sync with the server.

Worth it? The right direction; DartWay is heading there too. It is marked experimental for now, and it will take time to mature.

Future calls and shared models​

Background jobs are declared as ordinary Dart methods, and recurring ones are supported. Models can live in a separate package shared by the server and the Flutter app.

Worth it? Sharing models between frontend and backend is a well-known pain, and it was one of the reasons we left Serverpod. Now it is there, and it is a sensible step.

Serverpod Cloud​

Deploy the backend, the database and the web app with one command, from $5 a month. The framework is free and the business is hosting — a clear model.

Worth it? Today an agent sets up infrastructure in a couple of prompts: a server, Docker, the database. And if you do not understand how your server is built, handing it to someone else is uncomfortable either way.

App Studio​

A desktop app with Flutter, Dart and Serverpod already inside. There is no AI of its own: you plug in Claude Code, Cursor or any other agent. What comes out is an ordinary project with its code in your hands — not a closed sandbox like Lovable.

Worth it? Two reservations.

The first: Serverpod gives you a tool for each task, but it does not tie them into an architecture. To build everything on that list well you still have to be the architect of your app, or it turns into a mess. We ran into that many times when we built on Serverpod directly, before DartWay existed.

The second matters more. Real development does not get stuck on setting up the environment. A prototype or a first version is easy. It gets hard when there are many screens and features that have to stay consistent with each other, and a large set of requirements that must hold precisely. A chat window next to a running app does not help with that: where do all the requirements live, and how does it all stay in sync? That is the question that decides whether a real product gets built, and App Studio does not answer it.

Verdict​

A good release of a good framework, and worth a look if you build fullstack Dart. Most of it makes the local loop nicer; the hard problems of agent-driven development — architecture, and keeping a large product consistent — are left to you.

The video version, in Russian, is on YouTube.

That sounds alarming and mostly is not — today. Here is what we found migrating a real project from 3.44.0 to 3.47.2, and the one widely repeated claim about this release that does not survive contact with the code.

Nothing is on fire today​

We took a live project from 3.44.0 to 3.47.2 and ran it: flutter analyze clean, tests green, the libraries still inside the SDK and not marked deprecated. The deprecation is scheduled for the November release. That is when the clock starts.

So this is a good month to migrate and a bad month to panic. The window exists precisely so the migration is boring.

The migration is one command, with two traps​

dart fix --apply --code=migrate_design_widgets

Trap one: plain dart fix --apply will not do it. The fix is not in the default set; without --code=migrate_design_widgets the command runs, reports success, and changes nothing relevant. It is the kind of failure that reads as "already migrated".

Trap two: it writes material_ui: any into your pubspec. any means the next breaking release of that package lands in your build without a word. Replace it with a caret and a version the moment the fix finishes.

The claim that is not true: ChangeNotifier did not move​

The most repeated line about this release is that ChangeNotifier and friends were pulled out of the SDK into package:listen. In 3.47.2 that is not what happened.

The classes are still in the SDK, and they are not marked deprecated. listen is a second, independent implementation of the same names — not a new home for the old ones. The two are separate types, and the compiler treats them that way:

• hand a listen ValueNotifier to a Flutter ValueListenableBuilder and you get a compile error, not a subtle runtime bug;
• the same applies in reverse, and to every other pair with a shared name.

Where listen earns its place is code that has no Flutter in it: a server, a CLI, logic shared between the two. There the SDK types were never available and now there is an equivalent. Inside a Flutter app, switching to it today buys nothing and costs you type compatibility with every widget that expects the SDK version.

Primary constructors will not turn themselves on​

Dart 3.13 ships primary constructors, and they are behind a language version gate. Without sdk: ^3.13.0 in pubspec.yaml you get experiment_not_enabled even on the right SDK — the toolchain is correct and the project is not asking.

Worth saying plainly, though: the value of saving constructor boilerplate drops a long way once the boilerplate is not written by a human. If your constructors are generated, this is a readability change, not a productivity one.

The rest​

Impeller by default on desktop, iOS 15 and macOS 12 as the new floors, and the Wasm work — all real, none of it urgent, and none of it changes what you do this month.

What to actually do before November: run the migration on a branch, pin material_ui properly, and leave ChangeNotifier alone.

Checked by migrating a live project from 3.44.0 to 3.47.2 — before/ and after/ each build and pass their tests on their own SDK. The video walkthrough is on YouTube.

Here is what it actually costs, in the order the costs show up.

The lookup was never the problem​

The framework stored a single userIdentifier column and matched it by strict equality. Ask it to find a profile by phone or email and there is no seam to extend — not because the query is hard, but because authentication itself requires that column to exist. Remove it and the core fails at startup.

So the first fix is not "search two fields". It is giving the application a say in how a user is found:

DwAuthConfig(
  findUserProfileByIdentifier: (session, identifier) async {
    // the app decides what "the same person" means
  },
);

The column stops being mandatory, the identifier arrives already normalised, and the framework stops pretending it knows what identity means in your domain. Three obligations move to the application, and the docs say so out loud — a resolver that silently does the wrong thing is worse than no resolver.

Searching two fields fixes nothing on its own​

This is the part that surprised us, and it is the reason this post exists.

A user who signed up by phone has an empty email column. Searching both fields finds nothing new, because there is nothing in the second field. The lookup is correct and useless at the same time.

To fill that column you need a way to attach a second channel to an existing account — which means addAuthProvider and changeIdentifier have to actually work. In our case both threw UnimplementedError, and there was no screen for it in any mockup. Until that exists, signing in from the other channel keeps quietly creating a second account, exactly as before.

The duplicates are already there​

Then comes the part you cannot postpone. We went to add unique indexes on phone and email and found there were no unique indexes at all — not on the new columns, not on the old userIdentifier. Two rows with the same value were already legal, and the lookup resolved to whichever one the database felt like returning.

You cannot add the index until the duplicates are merged. And the duplicates exist precisely because login from a second channel used to create a new account. The bug and its cleanup are the same object.

Merging is an event, not an action​

Account merge is irreversible: one profile absorbs another, and afterwards nobody can reconstruct what came from where. So we modelled it as a ProfileMerge event rather than a method call — who merged, whom, and what moved. An action leaves the database consistent and the story gone; an event leaves both.

What we would tell ourselves a week ago​

• "Login by phone or email" is not an auth-screen task. It is a profile identity task, and the screen is the last five percent.
• Ship the attach-a-second-channel flow in the same release. Without it, the feature is a lookup that finds nothing.
• Check for unique indexes before you promise anything. Ours were missing for the entire life of the project, and nobody noticed because nothing enforced them.
• Verify on a live database with a real round trip — phone signup, email attach, email login into the same account, one row in the table. We had 23 server tests including that pass; the reading-the-code version of this article would have been wrong in two places.

The framework side landed in dartway core 0.12.1 — the auth resolver and a working changeIdentifier. If you are running the earlier version, the migration is the interesting part, not the API.