React Native vs. Flutter: My Experience Building a Small App

3 min
Experiences

This is a record of my experience building a small Android and web control panel in 2024. It is not a current feature comparison or a performance benchmark. React Native, Expo, and Flutter continue to change; check their current documentation before choosing a stack.

I was building a control interface for a device, with the option to make it a mobile app or a web app. The cross-platform approaches I knew were React Native and Flutter. I started with React Native, ran into too many problems for this project, and switched to Flutter. In my case, I rebuilt in two hours what had taken several days in React Native.

Environment setup

React Native projects use JavaScript or TypeScript and npm. Expo can build through EAS in the cloud, and a project can also be configured for local Android builds. The available workflows and platform requirements change over time; see the current Expo EAS Build documentation rather than treating my setup as a current limitation. At the time, I found Expo builds slow.

Without Expo, a React Native Android project needs a JDK, the Android SDK, and other command-line tools. Flutter also needs its SDK and Android tooling. I had an easier time getting my Flutter setup working, but that was my experience with these particular projects and machines.

Expo builds also stalled for me on network requests. I suspect that was related to my network at the time, not an inherent property of Expo.

Development experience

React Native uses JavaScript or TypeScript; Flutter uses Dart. I was unfamiliar with both languages, but could get started from examples, so the language itself did not decide the project for me.

I found Flutter’s tutorials and documentation easier to follow. With React Native, it was not always clear whether advice for web React also applied to React Native, so I could not reliably paste a solution from a web React discussion. I also disliked the size of the node_modules directory.

For this project, Flutter felt easier to work with.

Libraries and navigation

I often needed polished components. I found that some React libraries I wanted were not compatible with React Native. In an early attempt with create-react-native-app, I also struggled to understand routing and how the web target was meant to be deployed. Expo solved some of those problems, but I did not enjoy its build workflow at the time.

I had not encountered the same issues in Flutter yet. That reflects the scope of one project, not a complete comparison of either ecosystem.

Android build output

I wanted Android packages split by ABI because I mostly use an aarch64 device. Android App Bundle and APK outputs, ABI splits, and build profiles depend on the project’s Gradle configuration and distribution method. My 2024 setup required native Gradle changes, and I found that workflow more direct in Flutter.

Expo/EAS projects can also customize native builds. The details depend on the project’s prebuild and Gradle configuration; see Expo’s current Android build documentation. EAS CLI currently documents local builds as experimental, so check the current EAS CLI reference before selecting that workflow.

In my own builds, the Expo package was largest, create-react-native-app came next, and Flutter was smallest. That result depends on app code, dependencies, and build configuration, so it should not be generalized.

App performance

I did not benchmark the released apps. I had read comparisons that favored Flutter, but I did not verify those claims myself. I cannot draw a performance conclusion from this project.

Conclusion

For my small Android and web control panel, Flutter was a better fit at the time: I had fewer setup and workflow problems and finished the rewrite quickly. Your result may differ with a different team, app, platform requirements, or current framework versions.