The title was blunt: native is now the future of mobile at Shopify.

Six years ago they went all-in on React Native. Last January, Ali wrote a retrospective saying RN had a bright future. Now they are reversing course, and the stated reason is one thing: coding agents have crushed the cost of writing everything twice.

The switch worked out. Six engineers took Shop App from proof of concept to the app store in 12 weeks. iOS cold start improved 23%, Android 50%.

But the most valuable line in that post is not a number.

Ali writes that an agent can rewrite the code in seconds, then spend minutes working out whether it actually works. Simulator control is too slow, so getting state means going through the accessibility tree or taking screenshots.

His words: if the model cannot quickly verify its own work, it does not matter how good the model is.

That complaint made me read two posts side by side. The Shopify piece from September 10 and the Flutter team’s response forty days later are arguing about the same thing.

The bottleneck is not generation, it is verification

The Flutter post went up on October 20, by Carlos Mendonça and Emma Twersky. Its title is just as blunt: AI makes it easy to migrate, Flutter makes it easy to scale. It exists to answer the question Shopify threw down.

The whole piece rests on one claim. Code generation stopped being the bottleneck a while ago. Verification is the bottleneck now.

Two numbers back it up. 73% of developers say AI makes them more productive when starting a task. 46% do not trust AI’s debugging accuracy without a human checking it.

Squeeze from both sides and the blocker sits on the human side.

The bill for three steps

The team published a comparison table putting native and Flutter next to each other across the three verification steps.

Code-to-running latency: native takes 2 to 5 minutes per cycle. Build, link, archive, install on the simulator. Four debug rounds burn twenty-odd minutes.

Flutter stays under 200 milliseconds. Hot reload injects the change into a running Dart VM and keeps state.

Automated tests: native walks the full simulator lifecycle and a background emulator. Flutter’s headless widget tests run in an isolated environment in under 500 milliseconds.

The UI and state-check row is where it gets interesting.

Native screenshots the simulator and hands the image to a vision model to guess at the layout. Probabilistic, and slow. Flutter goes through MCP to query the Dart VM Service and DevTools, reading the widget and render object trees directly. Deterministic, structured.

Chain the three and you have a complete loop. Every step queues on the native side. On Flutter a round trip is milliseconds.

Harness beats prompt

Fast verification is one thing. Getting the agent to actually use it is another. The team ran an internal experiment called Project One Shot, letting an agent fix a production bug in camera_android_camerax on its own.

The plugin manages Android CameraX lifecycles and surface texture binding, the hairiest kind of Flutter code there is.

Given vague instructions like watch out for memory leaks, the agent failed every time.

It only worked with a deterministic harness. AST analysis over MCP, package-level domain skills, enforced test-driven guardrails. Reproduce with a failing test, write the smallest fix, finish with the full test suite and leak checks.

No room for the agent to freestyle. Every step has its acceptance criteria nailed down.

Three things shipped alongside. An official Dart and Flutter agent plugin bundles an MCP server with ten Flutter and fourteen Dart skills, so the agent can reach the Dart Analyzer and Widget Inspector directly.

A dedicated agent inside Antigravity audits accessibility issues and submits fixes that match existing conventions. Plus an Agent Skills CLI built with Serverpod: one dart run skills@get installs the skills a package ships with into your agent.

The benchmark numbers: Gemini 3.5 Flash from 84.1% to 85.5%, Gemini 3.1 Pro from 89.6% to 92.7%. Modest gains, run by the team on its own eval suite.

Where this actually lands

The post lists a set of deployment targets well beyond phones. Toyota and Lexus head units, the Xiaomi SU7 center console, Nubank’s fintech app with a hundred million users, Universal Music.

The post does not push this angle. I think it is the most convincing part.

What these share is absurdly expensive verification.

Flashing a head unit takes tens of minutes. One production incident in a fintech app costs real money. Music app users tolerate zero jank.

In places like these, a minute off the verification loop is money and time you keep.

Look further out. Once agents writing code is normal, one codebase across platforms saves more than headcount. It saves time.

An agent produces a change, hot reload shows it on phone, desktop and web at once. That is an order of magnitude faster than compiling, packaging and installing per platform.

That is also why the Flutter team has been pushing into automotive, desktop and embedded.

The second half of cross-platform may not happen on phones.

A few things I do not buy

The app store rating section does not hold up. It cites Apptopia’s study of 201,000 apps. On Google Play, Flutter apps average 4.1 stars, and so do non-Flutter apps. On the App Store both sit at 4.0. The conclusion offered is that users do not care about the framework.

All that shows is that cross-platform did not hurt ratings. Flip it around and it also shows cross-platform did not help. Using a tie to argue for adoption is missing a step.

That 200 milliseconds is the time to inject a change. It excludes writing the code, thinking it through, switching windows.

It cannot change class structure either. Add a field or restructure the state tree and you need a restart.

The table measures code-to-running latency, which is an honest definition. Readers will take it as development being twenty times faster, and those are very different claims.

The enterprise examples have survivorship bias too.

Xiaomi SU7, Universal cutting 45% of its code, Toyota and Lexus, Nubank’s hundred million users. All real.

No post ever covers the company that moved to cross-platform for two years and then tore it out. Arguments from these examples are half evidence.

How to do the cross-platform math

Line up both sides first. Shopify’s call: the cost of writing twice has been crushed, and what is left is not worth giving up native capabilities for. Flutter’s call: coordination costs remain.

The example in the post is specific. Same checkout state machine, two instances of the same model. One writes Swift and drops stale events through an async stream. One writes Kotlin and queues events through a reactive flow.

Both pass local unit tests on day one. Weeks later Android checkout conversion drops three points, because under network jitter the retry timing differs.

Both positions hold. They are doing different arithmetic.

I also do not think this pivot is evidence that cross-platform is dead.

This is a company with hundreds of screens, over a thousand engineers, and mobile as a core investment. At that scale, rebuilding for 23% faster cold start and a better crash rate pencils out.

For five people maintaining a mid-sized app, the same move probably does not.

What decides whether you go cross-platform is team size, how many years you will maintain it, and how long your verification chain is. AI changes none of those.

Here is a question worth arguing about instead. If agents really do get a verification cycle down to a few hundred milliseconds, how much longer does native-feels-better hold up.

I would like to hear what is actually on your desk. Is your project single-platform, dual, or cross? What drove that call: performance, headcount, or a boss who said we are going native?

One more question: do you think Compose Multiplatform has a shot? It is cross-platform too, arrived years after Flutter, but it stands on half the Kotlin and Android ecosystem.

Drop a comment. I will pick a few representative ones and write them up as a follow-up.

Both source posts are here. Twenty minutes total.

Native is now the future of mobile at Shopify

AI makes it easy to migrate. Flutter makes it easy to scale.

Anyone writing an AI chat client runs into this: the model does not hand you the answer in one go. It dribbles out token by token, wedging tool calls, code blocks and stretches of thinking in between. The user staring at the screen is really watching a tree grow while someone keeps rearranging it.

The GetPullRequest team wrote a long post recently about how they built this in Flutter. The sharpest line is about Flutter’s official GenUI package:

It only drew the UI after the model’s full response had arrived and been parsed.

Which means it waits for the whole answer to arrive and be parsed before drawing anything. For a normal Q&A, waiting a few seconds is fine. For an agent doing twenty minutes of work, it is not: the tool card should have appeared long ago and you are still looking at a spinner.

I reproduced the key scenarios from that post on macOS and measured them. Three pitfalls here, each with a number you can produce yourself.

Pitfall one: re-parsing Markdown on every token

The most naive approach: a slice of text arrives, you throw the accumulated full text at a Markdown parser, get the node tree, render it. Looks like the obvious thing to do. The cost is that you re-parse what has already been parsed, every single time.

I took an 886-character agent reply as a sample: prose, a three-row table, a dart code block, a two-level nested list. I sliced it into 222 four-character chunks to simulate streaming. Here is how the three approaches compare.

28 milliseconds does not sound like much, but it is not spread evenly across 222 chunks. The first 50 chunks average 0.046 ms, the last 50 average 0.199 ms. It gets more expensive as you go, because the accumulated text gets longer. This is quadratic work: for an 886-character reply, the naive approach processes about 98K characters, 111 times the original.

Real-length answers make it obvious. Same approach, reply length doubles, time goes up two to three times:

886 chars / 222 chunks: 16 ms
1774 chars / 444 chunks: 61 ms
3550 chars / 888 chunks: 229 ms
7102 chars / 1776 chunks: 899 ms

A frame budget is 16.7 ms. By the 3550-character tier, just parsing the tail eats several milliseconds, and add layout and paint on top and dropped frames are inevitable.

The post’s fix is block-level incrementality: completed blocks parse once, only the growing one is re-parsed, and “notify the UI on every chunk” becomes “coalesce notifications into one microtask.”

Line-by-line parsing shreds the structure

There is a sneakier pitfall, tied to a product requirement: letting users select and comment on individual lines. If your render layer is one widget per line and each line is parsed separately, Markdown structure falls apart.

The same content, parsed line by line, produces this tag sequence:

[p, p, p, p, p, pre, p, p, pre, ul, li, pre, pre]

Parsed in chunks it produces this:

[p, table, thead, tr, th, th, tbody, tr, td, td, tr, td, td, pre, ul, li, li, li]

Compare the counts. The table: 0 tables when parsed line by line (a four-row table turns into five lines of pipe-separated text), 1 when parsed in chunks. The code block: 4 pre tags line by line (it should be one unit), 1 in chunks. The nested list: only 1 li line by line (it should be three levels), 3 in chunks.

The nested list case is the easiest to miss. In Markdown, four leading spaces mean “this is code,” so the moment the second level of a list gets parsed on its own it turns into a code block, shown on screen as a grey box with a bare minus sign in front of it.

One more basic pitfall while we are here: the markdown package only parses tables with the extension explicitly enabled. The default Document() yields 0 tables; switch to ExtensionSet.gitHubWeb and you get 1.

And one that is specific to streaming: a chunk can break in the middle of three backticks. When I fed that half-finished text to the parser, the one or two trailing backticks became literal characters in the body, so two lonely ` pop up on screen and only turn into a proper code block when the next chunk arrives. And if it happens to be a complete triple backtick with no content yet, you immediately get an empty code box.

Pitfall two: you scroll up, it yanks you back to the bottom

The chat list is reversed (newest at the bottom, offset 0 is the bottom). The user scrolls up 300 pixels to reread history. A new token arrives, and if the code does no checking and just scrolls to the bottom, the view is dragged back 300 pixels by force.

Measured: offset jumps from 300 to 0, the viewport is pulled 300 pixels. The paragraph being read vanishes.

Change it to “only auto-scroll when within 200 pixels of the bottom” and at that same offset of 300, the offset stays at 300 when new content arrives. The user is left alone.

The second source of jitter is card expansion. A card above the viewport grows from 100 pixels to 400, visible content shifts 300 pixels, and whatever was under your finger drifts away. The fix is to measure the height difference first, then after that frame’s layout, move the scroll position back by the same distance. Measured: compensating 300 pixels leaves 0.0 pixels of residual anchor drift.

The post also mentions the reverse case: expanding is easy, collapsing is hard, because Flutter has already adjusted the scroll position before you get a chance to fix it. You have to remember the position from before the change.

Pitfall three: treating one long reply as one widget

The first two pitfalls live at the text layer. The third is at the list layer. The old way stuffs one reply into a single Column with tens or hundreds of blocks inside. The problem is that as soon as Flutter sees any part of that widget on screen, it has to build the entire Column.

Measured with 500 blocks:

232 ms is fourteen frames. It janks the first time you open it. A 30 ms update also drops two frames. Split into blocks, the first render builds only 14 and is an order of magnitude faster.

Then there is notification frequency. Twenty chunks arrive in one event loop. Call notifyListeners() on each and the UI is asked to refresh 20 times. Coalesce them into one microtask with a small flag and you get 1 notification. Same result on screen, nineteen copies of wasted work gone.

The line from that post I agree with most, and the conclusion of all three sections:

the widget that owns a stream should be the smallest widget that shows it.

Which means: whoever owns the stream owns the listening. Do not let one big thing listen on your behalf.

How to read these numbers

The caveat first: these were measured in a headless flutter test environment, counting CPU time for parsing, building and layout, excluding GPU rasterization. So read them as magnitudes and relative differences, not as real-device frame rates. On a real device you also pay for font shaping and image decoding, so it only gets worse.

The three pitfalls are three facets of one thing: all of them pay repeatedly for content already processed. Full re-parsing re-parses. One widget for a whole reply rebuilds. Notify-per-chunk refreshes. What needs fixing is not three pieces of code but one habit.

One unavoidable piece of context: many people reach for flutter_markdown and hand Markdown to the official package, but it is unmaintained on pub.dev. The last release stopped at 0.7.7+1 in May 2025, and the package page points to flutter_markdown_plus as the successor. On streaming rendering, the official path is currently broken, and the community and every client vendor are writing their own.

How do you handle streaming Markdown? Chunk-by-chunk parsing or full re-layout? Tell me in the comments.

Adding AI to Flutter used to mean two roads: stuff the model key into the app and call it directly, or hand-assemble requests with http. The first is handing over the keys; the second has you hand-crafting a shoddy framework by day three, patching in retries, streaming, tool calls and structured output one at a time.

On October 8, Genkit Dart shipped 1.0:

Today, we’re announcing Genkit Dart 1.0, the first stable, production-ready release of Google’s open-source framework for building AI-powered features and agents in Dart.

This post isn’t chasing the news cycle. It answers two questions: what 1.0 actually did, and what Dart developers can take away from it.

One API, four model providers

Gemini, Claude, OpenAI, and every OpenAI-compatible service go through the same interface. Providers register as plugins, so swapping models doesn’t touch business code:

final ai = Genkit(plugins: [googleAI(), anthropic()]);

final fromGemini = await ai.generate(
  model: googleAI.gemini('gemini-flash-latest'),
  prompt: prompt,
);
final fromClaude = await ai.generate(
  model: anthropic.model('claude-sonnet-5-5'),
  prompt: prompt,
);

For developers in China, the more practical part is the “OpenAI-compatible” bit: services like DeepSeek get a first-class handle in the genkit_openai plugin. deepSeek.model('deepseek-flash') is the entire config — no assembling a baseUrl by hand and pretending to be OpenAI.

flow: typed AI functions that can also be your server

Google defines a flow as strongly typed, observable functions. My read: wrap AI logic into a function whose input and output both have types.

Types are written once in Dart with schemantic:

@Schema()
abstract class $RecipeRequest {
  String get dish;
  int get servings;
}

The server uses it to constrain model output, and Flutter uses the same type to parse the result. The hand-written jsonDecode plus as Map layer in between can be deleted wholesale:

final recipeFlow = ai.defineFlow(
  name: 'recipeFlow',
  inputSchema: RecipeRequest.$schema,
  outputSchema: Recipe.$schema,
  fn: (RecipeRequest input, _) async {
    final res = await ai.generate(
      model: deepSeek.model('deepseek-flash'),
      prompt: '给我一份 ${input.servings} 人份的「${input.dish}」的做法。',
      outputSchema: Recipe.$schema,
    );
    return res.output!;   // already a Recipe here
  },
);

A flow can also be mounted as an HTTP endpoint directly, with the client calling it through defineRemoteAction and the same schema shared:

final router = GenkitRouter()..addAction(recipeFlow);
final server = await router.serve(port: 8123);

On the wire it’s {"data": {...}} in, {"result": {...}} out. For Flutter developers that means one type serves as both the interface doc and the parser.

Three placements, you decide where the key lives

This is the most substantive thing in 1.0, I think. Google states outright that AI logic can live in three places:

• Directly in Flutter, good for prototypes and bring-your-own-key scenarios
• On a Dart server, keeping sensitive prompts on the backend, with Flutter calling through defineRemoteAction
• AI logic stays in Flutter, model requests go through a lightweight Genkit backend that protects the key and handles auth

The line from the announcement is worth copying down: never embed private API keys in a published client app. We used to embed keys in clients because reality forced us to. Now there’s a legitimate way out.

Tools, interrupts, middleware

Tools let the model call your Dart functions. For actions that genuinely need a human nod, a tool can return .interrupt(...), suspending the generation loop until the client confirms:

fn: (input, ctx) async {
  if (ctx.resumed == null) {
    return .interrupt({'hotel': input.hotelName, 'total': input.totalPrice});
  }
  return .response(confirmation.id);
},

The approval lives inside the tool, so the model can’t route around it. Google’s words: Putting the approval check inside the tool guarantees that the model can't bypass it. That is far more reliable than prompt engineering to keep the model in line.

On middleware, automatic retries, dynamically loading skills from SKILL.md, tool approval allowlists — all one line of use: [...] on generate. To write your own cross-cutting logic, defineGenerateMiddleware leaves the door open.

Prompts and production observability

Dotprompt keeps templates, model config and input/output schemas in .prompt files, auto-loads from the prompts/ directory, and you call it like a function in Dart:

final introPrompt = await ai.prompt('destinationIntro');
final response = await introPrompt({'destination': 'Kyoto'});

Once you’re live, genkit_otel exports traces, token usage and latency per OpenTelemetry’s GenAI semantic conventions, plugging straight into whatever observability backend you already run.

Two still in the experimental zone

Stateful agents and generative UI. The first is defineAgent, folding model, tools, system instructions and session state into one definition, with sessions surviving restarts via a session store. The second is genkit_a2ui: the agent stops emitting only text and starts emitting components like date pickers, forms and confirmation cards, which Flutter renders incrementally into native widgets.

Both import from package:genkit/experimental.dart. Try them early without carrying the stable-release baggage.

What developers actually take away

First, four kinds of glue you no longer write: multi-vendor adaptation, structured output parsing, streaming, and tool calls with retries. All four used to be rewritten for every model you onboarded. Now they’re in the framework, and the code goes from “rewrite it every time” to “it’s there when you plug in”.

Second, two things moved to the right place. The key moved from the client back to the server — that’s the security account. The schema moved from docs into code — that’s the interface contract. Anyone who’s done this once knows what those two save you is months of manual work later.

Third, adoption can be incremental. Start by using it as “a library that can call models”, add flows when you need them, and only then think about agents. Nothing demands you swap your architecture in one go.

I ran all four scenarios on my machine, all hitting a real model (DeepSeek), not paper reasoning:

[flow]   typed output → 番茄炒蛋（2 人份）| 6 steps / 15 min / 1812ms
[tool]   finishReason=interrupted → stop after restart
[client] remote response → 葱油拌面（1人份） | 5 steps | 2686ms
curl  →  {"data":{...}} in, {"result":{...}} out

Two hurdles before you start

Now the down side. 1.0 has an invisible threshold: it requires Dart SDK 3.12 or above. My machine had 3.11.1, so dart pub add genkit quietly installed 0.16.1 for me — no error, no warning. After you upgrade the SDK there’s a second one: the code generator was split into a separate schemantic_builder in 1.0, and if you miss it build_runner prints wrote 0 outputs — again, zero errors.

Two self-check commands, take them:

dart pub deps --style=compact | grep "^- genkit"   # see the version you actually got
ls lib/*.g.dart                                    # check whether codegen really hit disk

What I haven’t verified

Being honest: the Dev UI (genkit start, needs genkit-cli from npm), middleware, how Dotprompt actually behaves at runtime, genkit_otel exports, and the two experimental ones — I didn’t run any of those locally this round. What’s written above is the official documentation’s account.

Worth mentioning: the official example is already in your local cache, at ~/.pub-cache/hosted/pub.dev/genkit-1.0.0/example/http_server_example.dart. Streaming, auth and custom routing are all in there. Read it before you start and you save half a day.

If your Dart project were getting its first piece of AI logic, would you put it in the app or on the server? Comments welcome.

A partial list of the other fixes:

v1.7.6

• #34684 The return type of the almost never used ParentDataWidget.debugDescribeInvalidAncestorChain method is now Iterable<DiagnosticsNode> instead of String. Existing uses can call .join('\\n') on the return value if they need to continue to use a String instead of a DiagnosticsNode.

v1.7.4

• #30069 Text inline widgets allows embedding arbitrary widgets inline with text. TextSpanhas also been reworked to inherit from InlineSpan, in order to support WidgetSpan, which is used to define inline widgets. Existing uses of TextSpan should not assume the object is of type TextSpan anymore.

v1.7.1

• #33480 The FadeInImage widget no longer supports the placeholderSemanticLabelproperty.

v1.6.7

• #32374 The Image widget now supports two new properties: frameBuilder, and loadingBuilder, which enable callers to easily add a placeholder image which the image ios loading, add effects to the image once it loads (such as fading it in), and monitor the loading progress of the image (e.g. to show the user a loading indicator).

v1.6.3

• #33148 ExpandIcon now uses Colors.white60 instead of Colors.white54 when dark theme is used (ThemeData.brightness is set to Brightness.dark).

v1.6.2

• #32936 cleaned up the ImageStream listener API. addListener() and removeListener()now take an instance of ImageStreamListener, which contains references to the individual callbacks. See the announcement for more information.

v1.6.1

• #32528 Tapping a modal bottom sheet no longer dismisses it by default.

v1.6.0

• #30983 To support structured error messages #27327 the signature of InformationCollector and the context parameter of the FlutterErrorDetails constructor were changed. This should not impact you unless your package is attempting behave like part of the Flutter framework. See this comment which discusses how to write code that is forwards and backwards compatible with this change.
• framework #31569/engine #8695 Rect and RRect are now const constructable and are backed by 64 bit doubles rather than 32 bit floats internally.
• framework #31917 <- engine #8796 <- dart 1dd0f88c84 Fixes bug in StreamIterator which allowed constructor argument to be null. Also allowed await for on a null stream. This is now a runtime error.
• #30884 TabController.animationController changed to be unbounded to allow DefaultTabController to handle changes to number of tabs (after initial build).