15+ Years of Native iOS/Android — and Three Times I Still Choose Flutter

I started building iOS and Android apps in 2009. The languages shifted along the way — Objective-C to Swift on iOS, Java to Kotlin on Android — but I always built in “native,” the language each platform natively supports. On projects that wanted iOS and Android released at the same time, I’d lay the Swift code and the Kotlin code side by side in the editor and write the same screen transitions in both, almost like simultaneous interpretation. That’s how I worked for a long time.

So my conclusion — “if you want the highest-quality app, it’s Swift on iOS and Kotlin on Android” — hasn’t wavered to this day. Nothing beats native; I genuinely believe that.

And yet, lately, there are times I deliberately reach for Flutter — the cross-platform framework that lets you build iOS and Android from a single codebase. Today’s piece is about when I make that choice.

I used to turn it down

This isn’t my first encounter with cross-platform. Long ago, on request, I tried Adobe AIR and React Native. But to someone used to building in native, the quality back then just wasn’t satisfying, and I often declined those requests outright. If I’m honest, it was closer to avoiding them.

Years have passed since. Of the many cross-platform frameworks that appeared and then quietly vanished, React Native and Flutter have survived. Seeing that, I reconsidered. Maybe their quality has now reached a point that’s good enough.

”Which is highest quality” and “do I need highest quality this time” are different questions

The thing that mattered here was to separate the questions. “Which is the highest quality” and “does this project need the highest quality right now” are entirely different questions.

Native’s real strength is being able to build for the device exactly as you intend, down to the timing. Take Bluetooth. How much data arrives per second, whether you take all of it in or sample once every so many milliseconds — this kind of tight timing control is something you can write exactly as you want it, precisely in native. Camera and GPS are the same, and the more deeply you use devices whose behavior differs between iOS and Android, the more native’s edge tends to show.

Turn that around, and it means: for an app that doesn’t need that kind of fine-grained work, building it cross-platform carries far less risk of falling into a pit.

Three times I choose cross-platform

So, concretely, when do I choose cross-platform? It comes down to roughly these three cases.

① An early-stage product that hasn’t found Product Market Fit yet. At a stage where you don’t even know whether anyone will use it, building both iOS and Android natively at once takes real stamina. Build it cross-platform first and validate the idea in the market, and even if it misses, the damage stays small. It’s the stage where you keep the initial investment down.

② An app centered on presenting information in the UI, not advanced device control. A news app that fetches information from a server and shows it on screen, an app for posting and sharing photos — things where graphical presentation is the core and there’s none of that tight device control like the Bluetooth example. These apps suit cross-platform.

③ An app with a limited service period. Something time-boxed, like a campaign or an event. As long as it meets condition ② (it doesn’t use the device deeply), there’s no need to keep evolving it over the long term afterward. Since realizing only the requirements you know today is enough, the estimate rarely goes off course. Here too, cross-platform’s advantages are large.

Knowing it deeply is what lets you let go

These three lines are ones I probably couldn’t have drawn if I hadn’t handled a wide range of projects in native code — Bluetooth, camera, GPS, various sensors, connections to external devices.

Because you know what native can do, you understand what you’d be giving up by going cross-platform. “This part is safe to let go of,” “this part must not be let go” — you can draw those lines without hesitation. Deep experience shows its worth precisely in this kind of subtractive judgment. (I wrote about that idea — “the deeper and broader your knowledge, the deeper your judgment” — in a separate article, too.)

So I started learning Flutter

So that I can properly offer clients “cross-platform as an option” in those situations, I chose Flutter and actually started using it.

I didn’t choose React Native, which I’d handled before. Back then I saw a structure where complexity tangled around the linking of third-party dependencies, and I felt there was no future in continuing to build on it. (That said, innovation may well have happened in React Native since.)

To be honest, how far Flutter really goes, and where the friction shows up, is something I’m gauging in real projects right now. Having been let down by cross-platform before, I don’t take a new tool on faith. But it’s precisely because I’ve done native for so long that I expect to spot its limits — and its right uses — quickly and accurately. What I find, I’ll keep writing up here.

In closing

Which technology you build an app in is one of the most consequential decisions you make before you ever start building. Whether to go with the highest-quality native, or whether cross-platform is enough for the goal at hand — that changes from project to project.

If you’re thinking about a new app and would like to talk it through from that very first tech-selection step, you’re welcome to reach out here.