I'm going to say something that will annoy people on both sides: it doesn't matter as much as the internet makes it seem.
We've been building client apps for a while now. At some point you stop having opinions about frameworks in the abstract and start having opinions based on what broke at 11pm before a client launch.
Here's what actually shaped mine.
The React Native thing nobody warns you about
The ecosystem looks massive until you need something slightly off the beaten path.
We had a project where the client needed to integrate with a specific Bluetooth SDK. There was a React Native wrapper - great. Last commit: 3 years ago. Issues open: 47. We spent a week trying to make it work, eventually wrote a native module ourselves, and explained to the client why a "simple integration" took longer than expected.
That scenario has played out more than once. The React Native package ecosystem is wide but a lot of it is maintained by one person who may or may not still care about the library.
The other thing: if you're on an older RN codebase and you've been avoiding the new architecture migration, you'll feel it eventually. We inherited a project like this once. It was not fun.
That said, hiring React Native developers is easy. The pool is large, onboarding is fast if your team knows JavaScript, and for most standard apps it just works without drama.
The Flutter thing nobody warns you about
App size.
I know everyone says it's fine now and technically they're right — Flutter apps have gotten smaller. But for clients targeting markets where users are on mid-range Android devices with 16GB storage and slow connections, "fine" is relative. We had a client in Southeast Asia who specifically flagged this after user feedback. Worth keeping in mind.
Also Flutter Web. We actually used it for a client project, not just tried it in a sandbox. It worked, technically. But the performance on low-end devices was noticeably worse than a standard React app, SEO was a pain to work around, and the bundle size made us uncomfortable. We haven't used it for a client since.
What Flutter genuinely gets right is UI consistency. This sounds boring until you've spent three hours on a call explaining to a non-technical client why the button looks slightly different on iPhone vs Android. With Flutter that conversation mostly doesn't happen. The widget system renders the same everywhere. For clients with strong design opinions this alone is worth a lot.
And Dart is honestly fine. Better than fine for large codebases. I was skeptical, now I'm not.
The thing that actually determines which one we use
We stopped asking "which framework is better" and started asking "what is most likely to cause pain 6 months after this launches."
Lots of third-party integrations we don't control? React Native.
Client cares deeply about pixel-perfect UI on both platforms? Flutter.
We need to hire fast and onboard someone in a week? React Native.
Greenfield project, small team, full control over the stack? Flutter is worth the conversation.
Neither framework has saved a badly architected project. And neither has ruined a well-run one. The state management decisions, the folder structure, the test coverage — those matter more than the framework in the long run.
Where I've landed
React Native for most things because the hiring pool is bigger and the integrations are easier.
Flutter when the project is right for it and more projects are right for it than they were two years ago.
The most useful thing I can tell anyone choosing between them: build the same screen in both before deciding. Not a tutorial screen. A screen from your actual app. The one that will be hardest. You'll know within a day which one feels less like fighting.
Would be curious what others have run into especially anyone who's migrated a production app from one to the other. That's a story I haven't lived yet and I'm not sure I want to.
Top comments (0)