A Native iOS Developer's Perspective on React Native vs. Flutter (Part 2)
This is the second part of the “A Native Developer’s Perspective on React Native vs. Flutter” article series.
I gained a taste of the cross-platform development process with React Native. Yet, I was convinced that cross-platform development could be even better. And that’s when Flutter was officially released. Since I wasn’t completely satisfied with the React Native platform I decided to give it a shot and see what Flutter had to offer. For testing, I chose to create a completely new cross-platform application.
Flutter is completely different from React Native in its internal implementation: in fact, it doesn’t use any native components but draws everything to look and act the same as its native counterpart. You can customize its components to the target platform, which also means that you can use iOS components on Android and vice versa. Think of it as something like Unity but for applications, or rather Qt. As for the native developer, this concept seemed terrible to me, but it suddenly worked.
Specifically, my plan was to make a simple, production quality, cross-platform application to try out this framework. After a little brainstorming, I decided to write a water reminder application. This is a relatively simple application which will allow me to test everything I’m interested in trying out.
Once again, after briefly finishing a course, I achieved an overview and feel of the overall framework and started developing my new application. The initial setup was so smooth that I couldn’t believe it was true. You literally download the SDK folder, add it to the bash environment, enter a few ‘brew install’ commands, and that’s it!
I further studied the common architectural solutions used in the Flutter ecosystem. Surprisingly, there are many more options than on the React Native platform, and most of them are built upon Streams. In my opinion, such abundance is due to the fact that the platform itself is quite young and hasn’t yet accumulated much experience. The architectural solution I’ve chosen is Redux, the same as used in React Native, to be able to compare the two technologies more accurately.
The Water Reminder app built with the Flutter framework.
During the development, I gained a positive impression of this platform and can’t remember any serious difficulties with it. The debugging process is much smoother than with React Native. Your IDE has a debugger that’s much more convenient than using another application for this purpose. Unfortunately you’ll still have to use a separate application for profiling. No weird runtime crashes. Built-in navigation support is a breath of fresh air. SDK updates are as smooth as possible. The only downside I can remember is the absence of some non-critical libraries I needed. This can happen because the platform is still very young, so it won’t be a problem soon. I’d also like to highlight that I really dislike the official localisation process, but at least it worked. In terms of performance and multithreading, things also look better than on React Native side.
Overall, I’m highly impressed with this platform despite all of my initial skepticism. However, as of today, the Flutter community is experiencing some lack of knowledge about best practices and architecture solutions.
This is the second part of the three-part article series. In the next part, I will compare React Native and Flutter based on my own experience. Other than that, we will discuss what technology should you choose for different scenarios: Flutter, React Native or Native development.