Home › Articles › One Spell, Every Kingdom

One Spell, Every Kingdom: Why Flutter Still Matters in the AI Era

Cross-platform was never about less code. It was about fewer decisions. And that gap is widening as AI makes code itself cheap.

By Ishaq Hassan · May 1, 2026 · 7 min read · Karachi, Pakistan

There is a metaphor I keep falling back on in conversations with founders and engineering managers: imagine you learned ONE magic spell that works in every kingdom.

Swift only works in Apple's land. Kotlin only in Android's. But Flutter? One spell, everywhere. Same codebase. iOS. Android. Web. Desktop. Embedded.

For the last six years, that pitch was usually answered with a tradeoff conversation: "yeah but native is faster, more idiomatic, has better tooling, the team already knows Kotlin..." Fair points, all of them.

But the conversation has shifted. AI happened. And the question I get most often is some variant of:

"If AI can write Swift and Kotlin in seconds, do I even need cross-platform anymore?"

I want to take that question seriously, because the answer matters for anyone making a hiring decision, a tech-stack call, or a career bet right now.

The hidden cost was never the typing

When founders asked me "should we go native or Flutter?" five years ago, the unspoken assumption was that the bottleneck of native was typing the same code twice. Cross-platform sold itself on "write once, run anywhere", which translated to "fewer hours billed".

That framing was always too narrow.

The real cost of going native is not the keystrokes. It is:

• Two parallel design conversations. iOS team wants a sheet, Android team wants a bottom drawer, neither is wrong, but now your designer is mediating two threads instead of one.
• Two parallel technical debates. "Should we use Combine or RxSwift?" on the iOS side. "Coroutines or RxJava?" on the Android side. Each decision compounds for years.
• Two parallel test infrastructures. Mocks. CI matrices. Device farms. Snapshot baselines. Doubled.
• Two parallel performance benchmarks. A regression on iOS does not tell you whether Android is also affected. So you measure both, every time.
• Two parallel hiring funnels. When your iOS senior leaves, you do not get to backfill them with the Android team. Different skill, different pipeline, different salary band.

Every one of those costs is paid in decision bandwidth, not just engineer hours. And decision bandwidth is the actual bottleneck of a small team.

What AI changed and what it did not

Now plug AI into the picture. GPT-4o, Claude, Cursor, every code-completion tool you can think of. They write Swift well. They write Kotlin well. They produce production-ready stubs in seconds.

So the "typing twice" cost has genuinely collapsed. AI absorbs that part. If your only complaint about native was "writing the same screen for two platforms", AI just ate that complaint for breakfast.

But here is the thing people miss when they extrapolate from "AI writes code" to "tech stack does not matter":

AI writes WHAT you ask. You still decide WHAT to ask.

The skill that AI does not replace is the skill of:

• Knowing whether this feature should be a sheet or a screen
• Knowing whether this state belongs in the widget tree or in a controller
• Knowing whether you should reach for an Isolate or a microtask
• Knowing whether platform channels or FFI is the right boundary
• Knowing whether your Android app's jank is in the layout pass or the paint pass

That skill takes years of building real apps and shipping them to real users. AI can scaffold the code once you decide. It cannot make the decision for you, because the decision lives in your product context, your team's strengths, and your performance budget.

Cross-platform is leverage on the decision layer

If AI compresses the typing cost to near-zero, what is left of the native-vs-Flutter conversation? Just the decision cost. And cross-platform's real win has always been on that layer.

Here is what I see in the teams I work with:

Native team with AI

AI writes the iOS Swift. AI writes the Android Kotlin. Both are technically correct. But the team still has to sync the two implementations every time the design changes, debate platform-idiomatic interpretations, run two CI pipelines, and own two device matrices. Velocity drops the moment the team grows past two people because coordination overhead grows superlinearly.

Flutter team with AI

AI writes the Dart. There is one implementation. One PR review. One test run. The designer's mock translates 1:1. When the design changes, the change happens in one place. AI did not just speed up the typing, it sped up the single-source-of-truth iteration loop.

Both teams ship. The Flutter team ships with fewer decisions per feature. Over a year that compounds into months of delivery time.

The "but performance" argument is mostly settled

Five years ago "Flutter is slower than native" was a conversation worth having. Today, with the engine improvements (Impeller is shipping, the new Dart-on-native-thread model lands FFI calls synchronously, garbage collection is well-tuned for 120 Hz), most of those gaps closed.

I am not saying there are zero scenarios where native wins. There are. If you are building:

• A camera-pipeline-heavy app where every millisecond of capture-to-frame matters
• An audio DSP product with sub-10 ms latency requirements
• A tightly platform-integrated app like a keyboard, accessibility service, or system-level utility

... native still has the edge, and you should pick it. But for the vast majority of products, the perf gap is no longer the bottleneck. The team-velocity gap is.

What I actually tell founders now

If you are a 1-3 engineer team building a product where the UI is rich but not pushing hardware limits, Flutter is the highest-leverage choice you can make in 2026. Here is why, in order:

1. AI accelerates Flutter even faster than native. Dart is a smaller-surface-area language than Swift+Kotlin combined. AI gets context-window wins from a smaller codebase. Your next feature lands in one PR, not two.
2. One hire serves three platforms. When you are hiring, you are not picking between an iOS person and an Android person. You are hiring a Flutter engineer who ships everywhere. Salary efficiency, recruiting time, onboarding, all compress.
3. The framework itself is open and improving in public. I have 6 PRs merged into flutter/flutter myself. The roadmap is visible. The contributor base is growing. You are not betting on a black box.
4. Web target is a free distribution channel. Same code runs in a browser. Demo links for sales, embedded mini-tools, marketing site components, all the same codebase.

The one place I push back: do not pick Flutter just because it is fashionable. Pick it because the decision-cost math works for your team size and product type.

Where the human still matters

Strip everything else away and what is left is this: AI made code cheap. It did not make judgment cheap.

The engineer who knows where to build (sheet vs screen, isolate vs microtask, FFI vs platform channels) and why to build (which feature unlocks which user behavior, which performance optimization is worth its complexity) is more valuable now, not less. AI is a multiplier. A multiplier on zero is still zero.

That is the real reason Flutter still matters in 2026. Not because cross-platform won the technical war. Because cross-platform compresses the decision surface where AI cannot help you.

One spell. Every kingdom. Same wizard.

Read the original take

This article expands on a LinkedIn post I shared. The post sparked enough good questions that I wanted to put the full argument in writing.

If you are a Pakistani engineer trying to break into framework-level Flutter work, my full playbook is in How I Got 6 PRs Merged Into the Flutter Framework.

FAQ

Also published on:

Ishaq Hassan is a Flutter Framework Contributor with 6 merged PRs into flutter/flutter, Engineering Manager at DigitalHire, and creator of the 35-video Urdu Flutter course listed on docs.flutter.dev. Karachi, Pakistan. ishaqhassan.dev.