Framework selection is one of those decisions that feels consequential at the time and sometimes turns out to be irrelevant, and sometimes genuinely determines whether the project succeeds. For the NanoRich mobile app — a real-time trading signal display that needed to update continuously during Korean market hours — the choice between Flutter and React Native was not academic. The specific requirements of the app made one framework clearly better suited than the other, and the reasoning is worth documenting in detail because it illustrates how to think about framework selection in general.
What the App Actually Needs to Do
Before comparing frameworks, it helps to be precise about what the app requires technically. The NanoRich app does four things: reads from a Firebase Realtime Database and displays updates as they arrive; renders a multi-card list that can change state many times per minute during active market periods; receives push notifications from a server-side trigger; and displays AdMob advertisements.
The first two requirements are the critical ones for framework selection. Firebase Realtime Database pushes changes to connected clients the moment data changes on the server. During peak market activity — particularly between 09:15 and 10:30 Korean time — a stock tracking five or six positions can generate dozens of state updates per minute across all tracked stocks. Each update needs to trigger a UI re-render. The rendering pipeline needs to handle this volume without dropping frames, introducing visible lag, or consuming battery at a rate that makes the app impractical to use.
This is not a casual requirement. It's the core experience of the app.
The State of Flutter and React Native in 2026
Both frameworks have changed significantly in the past two years, and a framework comparison written in 2024 doesn't reflect the current reality. In 2026, both Flutter and React Native have matured to the point where the gap between them has narrowed considerably in most use cases. But for this specific use case — high-frequency real-time UI updates — the difference remains meaningful.
Flutter's Impeller rendering engine, which replaced the older Skia engine and became the default for both iOS and Android in Flutter 3.27+, eliminates what was previously one of Flutter's persistent problems: shader compilation jank. Impeller precompiles all shaders at build time, which means the first time a widget renders, there's no compilation delay. For an app that displays continuously updating cards during active market hours, this matters. Benchmark data shows Flutter achieving consistent 60-120 FPS with frame rasterization times reduced by roughly 50% compared to the pre-Impeller baseline, with essentially zero dropped frames in continuous update scenarios.
React Native's New Architecture — Fabric renderer, TurboModules, and the JavaScript Interface (JSI) — has closed the performance gap significantly compared to the old bridge-based architecture. Cold start times are now around 350ms versus Flutter's approximately 250ms. Memory usage is higher: benchmarks show React Native using roughly 33MB more memory on Android than Flutter under equivalent loads. For apps with steady-state performance demands rather than burst activity, React Native's New Architecture performs well.
The meaningful remaining difference for this specific app comes down to how each framework handles the combination of continuous high-frequency updates and its rendering model. Flutter renders every pixel through its own engine — the UI update path from a Firebase listener firing to a widget repainting does not involve a native bridge. React Native, even with JSI eliminating the old asynchronous bridge, still processes UI updates through a layer that translates between JavaScript and native components. For most apps, this difference is invisible. For an app where the UI may need to process dozens of state updates per minute across multiple cards, it matters.
The React Native Option and Why I Considered It Seriously
I didn't dismiss React Native quickly. The NanoRich web interface is built in React, which meant there was significant code and logic that could potentially be reused if the mobile app shared the same JavaScript/React foundation. React Native would have let me build on a codebase I already knew well.
The specific advantage of React Native for this project would have been speed of initial development. The core logic for reading from Firebase and rendering the signal cards already existed in React; porting it to React Native would have involved adapting the layout for mobile rather than rewriting the core behavior. This could have cut development time significantly.
The reason I ultimately didn't go this route comes down to what I found when I tested both options against the actual update frequency the app would need to handle. I built a minimal prototype in both frameworks — just a Firebase listener rendering a list of cards with grade indicators, updating in real time from a test database — and ran them simultaneously against a simulated update load matching what the actual market data produces during peak activity.
The React Native prototype was smooth at steady state. When updates arrived in small batches, the rendering was clean and responsive. When I simulated the burst activity that occurs during the first few minutes after a major signal fires — multiple stocks updating simultaneously with high tick frequency — the React Native prototype showed occasional frame drops and a noticeable lag between the Firebase data arriving and the UI reflecting it. Not severe, but present.
The Flutter prototype showed no equivalent behavior under the same load. The updates rendered immediately as they arrived. Frame drops were not measurable.
Firebase and AdMob Integration
Two of the app's secondary requirements also favored Flutter, though less decisively. Firebase is a Google product. Its Flutter SDK — the FlutterFire package — is maintained by the Firebase team itself and is consistently the best-supported client outside of the web SDK. Updates to Firebase features appear in the Flutter SDK quickly. The Firebase documentation treats Flutter as a first-class platform.
AdMob is also a Google product. The google_mobile_ads Flutter plugin is maintained by the same team and has a straightforward integration path. Setting up banner ads and interstitials in Flutter required roughly four hours of integration work — most of which was account setup rather than coding.
React Native's Firebase and AdMob support is good but maintained by the community rather than by Google directly. The react-native-firebase package is high quality and widely used, but updates to Firebase features sometimes take weeks to appear in the community SDK rather than days. For a project where I expected to maintain the app over an extended period, first-party SDK support was a meaningful preference.
The Learning Curve Cost
The honest counterargument to choosing Flutter for a solo developer with a JavaScript background is the learning curve. Dart, Flutter's programming language, is not difficult to learn if you have experience in any modern object-oriented language — the syntax borrows from Java, C#, and Swift in ways that feel familiar quickly. But it is a new language, and the initial weeks involve a lot of documentation lookup that wouldn't be necessary in JavaScript.
For this project, the learning curve cost was approximately two weeks of slower-than-normal productivity at the start. After that, Dart's strong typing and Flutter's widget model felt natural, and development speed normalized. Whether that two-week cost is worth it depends on how long you plan to work with Flutter — for a single short project, probably not; for ongoing development of a real app that will be maintained, the longer-term advantages compound.
For the NanoRich app specifically, I expected ongoing development work — new features, Firebase structure changes as the backend evolves, potential iOS support later — and that expectation made the learning curve investment clearly worthwhile.
Today's Investing Insight — The Build vs Buy Decision in Financial Technology
The same framework selection logic that applies to mobile development applies in a different form to financial technology tools generally: when does it make sense to build something custom versus using an existing solution? The NanoRich signal board itself represents a build decision — building a custom signal detection system rather than using an existing one. The framework selection for the mobile app represents a different kind of build decision within that build. In financial services, the build vs buy question is particularly consequential because custom systems can be precisely tailored to specific workflows but require ongoing maintenance, while off-the-shelf solutions offer broader support but may not fit specific requirements well. The principle that consistently applies is to build only where the custom version genuinely adds value that the existing solution can't provide — and to use existing solutions, even imperfect ones, everywhere else. For the signal detection logic, custom was clearly necessary. For the mobile rendering framework, choosing the right existing tool was clearly the right call.
---
This post documents a personal journey of building a mobile application and reflects personal technical experience and perspective. Framework performance characteristics described here are based on testing conducted in a specific development environment and may differ in other contexts. All investment decisions and their outcomes are the sole responsibility of the investor.
Comments
Post a Comment