Most framework benchmarks you'll find are useless for making a decision. They measure a synthetic scenario — a list of ten thousand coloured boxes, an animation nobody would ship — on one device, in one configuration, usually by someone with a preference.

Your app's performance will be determined by your rendering patterns, your data volume, your images, and your dependencies. Not by which framework won a scrolling test.

This is how to get numbers that actually predict something, and what the architectural difference between the two genuinely costs.

The architectural difference, precisely

Flutter draws every pixel itself. The Impeller engine renders the entire UI to a canvas. No platform widgets are involved. Rendering is predictable and identical across devices, because the same code produces the same pixels everywhere.

React Native uses real platform components. A <Text> becomes a UILabel on iOS and a TextView on Android. Under the New Architecture, Fabric manages this through direct C++ bindings rather than the old async bridge.

The consequences that actually show up in practice:

  • Flutter's rendering is more consistent across devices and OS versions, because it doesn't depend on platform behaviour.
  • React Native inherits platform optimisations — including the OS's own scrolling and text rendering, which are heavily tuned.
  • Flutter has a larger startup cost because the engine must initialise. Measurable on low-end Android; negligible on recent hardware.
  • React Native's JavaScript thread is a shared resource. Heavy JS work competes with your UI logic. Fabric largely fixed the rendering consequence of this, but computation on the JS thread is still computation on the JS thread.

For ordinary application UI — lists, forms, navigation, images, detail screens — both comfortably hold 60fps on any device from the last several years. The framework is not your bottleneck. Your code is.

What to measure

Four numbers matter, roughly in order of user impact:

Cold start time. App icon tap to usable interface. Users feel this on every session and it's the most common source of "this app feels slow." Measure on a genuinely low-end device, not your development phone.

Frame timing during your worst interaction. Not average FPS — average hides everything. You want the distribution, specifically how often frames exceed the budget (about 16ms at 60Hz, 8ms at 120Hz). One dropped frame in a scroll is visible; a good average is not.

Time to interactive on your heaviest screen. Whatever loads the most data and renders the most complex layout.

Memory under sustained use. Navigate around for ten minutes. A leak shows up as steadily climbing memory and eventual termination on low-end devices.

How to actually measure it

Build one real screen in both. This is the only benchmark worth trusting. Take the most demanding screen in your actual product — your real API, your real image sizes, your real data volume — and build it in each framework. A day of work each, and it answers the question definitively for your case.

Profile with the platform tools, not framework counters.

  • Flutter: DevTools timeline view, and always profile in --profile mode. Debug builds are dramatically slower and benchmarking them is meaningless.
  • React Native: Flipper or the React DevTools profiler, plus Xcode Instruments and Android Studio Profiler for native-side work. Release builds only.
  • Both: Xcode Instruments and Android Studio's profiler give you the ground truth beneath either framework.

Test on the worst device you support, not your development machine. A high-end phone hides almost every performance problem you have. A budget Android device from three years ago reveals all of them.

Test on a slow network. Both platforms' simulators can throttle. Much of what users experience as "slow app" is actually "slow network with no loading state."

Where slowness actually comes from

Across the mobile apps we've profiled, framework choice has essentially never been the cause. These are, in rough frequency order:

Images. Loading full-resolution photographs into thumbnail-sized views. Enormous memory cost, significant decode time, and it's the single most common performance bug in mobile applications. Resize server-side and cache aggressively.

Rebuilding too much. In React Native, a state update re-rendering an entire list instead of one row. In Flutter, a setState too high in the tree rebuilding a large subtree. Both frameworks give you the tools to scope updates; both let you ignore them.

Unbounded lists. Rendering a thousand items when twelve are visible. Use the virtualised list components — FlatList with proper keyExtractor and item layout, or ListView.builder. Rendering everything is the most common cause of scroll jank in both.

Work on the wrong thread. JSON parsing, image processing, or cryptography on the main or JS thread. Move it off.

Too many dependencies. Every native module adds startup cost. Audit periodically — packages accumulate and are rarely removed.

Debug builds. Genuinely worth stating: people benchmark debug builds and conclude the framework is slow. Both frameworks are substantially slower in debug.

A realistic decision process

  1. Assume both are fast enough. For normal application UI, they are.
  2. Build your hardest screen in both. A day each. This is the only comparison that predicts your outcome.
  3. Profile both on your worst supported device, in release mode.
  4. If the numbers are close — and they usually will be — decide on team and hiring instead. That's the criterion that actually varies meaningfully between the two.

The framework question is genuinely less important than it feels. A well-built app in either outperforms a badly-built app in the other by a wide margin, every time.

If your measurements do show a real gap on your workload, that's valuable information — but it will be specific to what you're building, which is exactly why generic benchmarks couldn't have told you.

Want the measurement done properly?

We build and profile cross-platform apps in both frameworks, including performance audits on existing apps where the framework usually isn't the problem. Talk to us about app development.