Prequel
why was flutter even a thing?
this question hit me because react native went stable almost three years before flutter did. react native was already the popular choice, with its own ecosystem and momentum. so why did flutter even need to exist? what was it doing differently?
you'll hear people say flutter is "more performant." okay, but that's a vague answer and barely scratches the surface.
i wanted to understand the actual problem flutter was built to solve.
Chapter 1 - The Pain
up until 2014, shipping a quality mobile app meant writing it twice. java for android, objective-c for ios. two codebases, two teams, and duplicate bugs that somehow behaved differently on each platform.
naturally, developers wanted a shortcut. web dev was booming, so the obvious choice was to take html, css, and js, wrap it in a native shell, and ship it to both stores.
that's how we got cordova and ionic. the pitch was dead simple: take your web app, drop it in a webview, done. one codebase.
▸ what about xamarin?
yes, xamarin took a different path by compiling c# code to native views instead of using webviews. but it still struggled with huge app sizes, slow startup times, and constant issues connecting to native libraries. also, there were plenty of other webview wrappers at the time, like framework7, onsen ui, and sencha touch.
and people actually shipped real products with this. early notion ran on cordova. it worked. the dual codebase problem was technically solved.
but a webview is literally just a browser tab pretending to be an app. scrolling felt slightly off. animations were clunky. gestures had weird delays. users could tell it wasn't a real native app, even if they couldn't explain why. and for developers, debugging rendering bugs inside a wrapped browser engine was a massive headache.
the problem wasn't solved. it was just hidden until someone actually used the app.
Chapter 2 - The Rise of React Native
then facebook dropped react native in 2015. for the first time, cross-platform development genuinely made sense.
instead of rendering web elements inside a browser dom, react native mapped your javascript code directly to real native views. a <text> tag became a native text view. a <button> became an actual os button. it looked and felt native because it literally was using native components under the hood.
and if you already knew react for web? the transition was very easy. same jsx, same hooks, same component model, just targeting native ui instead of the dom.
Chapter 3 - The Fall of React Native (not really)
but there was a major catch in how it was built. your javascript ran on one thread, native ui on another. the only way they talked was through a bridge.
every tap, scroll, and animation frame had to be packaged into json, sent across the bridge, and unpacked on the other side. every single time.
for simple screens, it worked fine. but the second you had complex gestures or long lists, performance tanked. frames dropped hard. the bridge was a hard limit on what the app could do.
app sizes got huge, too, because all native modules were bundled in whether you used them or not. and whenever you needed a feature the framework didn't cover, you had to drop into android studio or xcode, write native code, and wire it through the bridge yourself.
then there was platform drift. you'd build a screen that looked perfect on ios, but android would show the spacing differently or slap on unexpected os-level styles. "write once, run anywhere" quietly became write once, debug everywhere.
Chapter 4 - The Rise of Flutter
this is where google stepped in.
most people think flutter started in 2018 when it hit stable, but the real beginning was in 2014 with an internal project called sky. a small team at google decided to try a completely different approach.
adam barth's first commit back in 2014. back then it was just an internal project named sky (engine).
flutter completely skipped the os widgets. it brought its own drawing engine (originally skia, now impeller) and painted every pixel directly onto a blank canvas. it didn't ask android or ios for a button. it just drew one.
this is why flutter isn't just a framework, it's an engine. it is basically a game engine built for apps.
Because there is no bridge and no need to pass data back and forth between threads, flutter runs at a smooth 60fps. animations stay smooth and gestures feel instant.
this is what people actually mean when they say "performance." flutter's goal was never just to run on two platforms. it was to own the whole system, from the language and tools to every single pixel on the screen.
Chapter 5 - The Re-rise of React Native
a lot of developers still judge react native by its 2018 bridge design. that version is dead.
meta rebuilt react native from the ground up. by 2024, the new design became the default for new projects.
the bridge is gone. it was replaced by jsi (javascript interface), which lets the javascript code talk directly to native objects in the same memory. there is no more packaging data into json.
they also shipped fabric, a new system that sits closer to the phone's hardware and handles layouts instantly without slowing down the screen. turbomodules killed the bloat, meaning native code only loads when you actually call it.
then there's hermes, meta's custom js engine built specifically for react native. it compiles javascript before the app runs, which makes it start up much faster.
react native today is genuinely solid. the performance gap with flutter is basically invisible for most apps. and expo has made the setup incredibly easy. with expo eas handling builds and live updates, solo devs and small teams can ship at a pace that used to require a whole engineering team.
Pre-Climax - Flutter vs React Native
so where does that actually leave us?
React Native, the goods
the react ecosystem is massive. if your team already knows web, picking up react native is quick.
the real advantage is that it uses actual native widgets. when apple ships an ios update with new ui behaviors, react native apps get them automatically. zero code changes.
this is exactly why react native handled new ios styling trends easily, since it was already using native views. flutter couldn't. it needed a manual rewrite or a custom override on top of the existing system.
but that native connection cuts both ways on android. android has dozens of custom brand skins, like samsung's or xiaomi's, and react native inherits all their random styling overrides. sometimes you get ui bugs you literally cannot control.
Flutter, the goods
flutter went the opposite direction entirely. it never touches native widgets. it paints everything.
with impeller, performance is very predictable. flutter compiles dart straight to native code, with no interpreter in the middle. this is why flutter apps run smooth even on cheap, low-ram android phones.
because flutter owns the canvas, you get absolute ui consistency. your app looks identical on a flagship pixel and a budget phone. no os overrides. no surprise styling changes.
this is why finance apps often choose flutter. when you have complex dashboards, charts, and lots of moving data, flutter's drawing holds up. react native can handle it too, but you will end up doing a lot of manual tuning to get there.
dart is also a genuinely good language. with safe code structure and clean syntax, anyone coming from java or kotlin picks it up in days.
Post-Climax - So Which One?
both are excellent engineering. the real question is what you're building.
Pick React Native if: your team already knows react. you are shipping an ios-heavy app where matching apple's native feel matters. you want expo's speed for quick builds and live updates.
Pick Flutter if: you are building something complex that needs to handle a lot of data. you have custom designs that need to look exactly the same across every device. you want to target other screens besides mobile. or if most of your users are on android.
the core difference is that flutter handles all the drawing itself, from top to bottom. you are never waiting on the os to draw your ui.
Post-Credits
that's the real story.
flutter was built to own the full chain. from code to pixels.
this is post 1 of the boring flutter. next one goes deep into flutter internals.
stay tuned.
