Flutter vs React Native – a cross-platform match
Our latest posts focused on going around a mobile build and enabling stakeholders to deploy cross-platform apps We’ve also written about various choices that would enable a cross-platform build to feel more or less native. Eventually, we dove into the inner workings of two particular frameworks and shared our findings for you to judge. The truth is, from our perspective. Both Flutter and React native are promising frameworks that would win or lose the duel within a particular business case. Nonetheless, we’ve promised a football match (by football we mean soccer) between these two nuggets. So here it is.
The coin toss (Initial Face-Off)
Both Flutter and React Native are strong opponents when talking about a cross-platform build. Howbeit, when it comes to their core strategies, these two are quite different. In matters of winners and losers, it’s literally a coin toss with quite a significant twist. When choosing, one must answer a few questions:
Do you have enough team members familiar with JavaScript?Should the UX be the same on both: Android and iOS?Is the “Native platform feel” a nice to have?
If you find yourself answering yes to at least one of these questions, React Native takes the lead. This is quite a simple ruling: a JS team can quickly adapt to the framework’s environment. With the wide selection of OEM widgets available to date there’s little to compromise over. Keep in mind though… For advanced builds, your team will also have to learn some Java and Swift to push a strong build.
Since this is a 50/50 ruling, you might also run a team that’s more familiar to Java, Kotlin, Objective-C, Delphy or C#. Here, Flutter takes the lead, as Dart is an object-oriented programming language, an ocean any profiled engineer would jump into.
In addition to the obvious OOP advantages, several challenges fade out exclusively when using Flutter.
For instance, if you ever dealt with a business scope, that relies on an environment where data is fed asynchronously […] you know that null references (a common trammel in such environments) can easily result in “billion-dollar mistakes”.
Anyone coming from a Java background knows that Kotlin stood behind facing those asynchronous issues. The resolution? “Reactive Programming”. This principle happens to be the main philosophy behind Dart, an inheritance that scores in favor of Flutter.
Flutter vs React Native 1:1
To sum up, we must qualify this face-off as 1:1. Both frameworks have something to bring to the engineering table when laid before a JS or Object-Oriented Programming team. EBS has both kinds in-house. The score is not only fair but would also avoid a “Civil War” over Flutter and React Native.
Popularity, engineering resources and adoption rates
When comparing these two in matters of popularity and adoption rates, there is not much to say. React Native uses JavaScript at its core. This means web developers with a dash of passion for mobile can release from simple to somewhat complex cross-platform apps. With relatively less effort. A Java-Script oriented approach to mobile development is neither good nor bad. It is simply healthy for the business leveraging fewer resources as compared to adopting a brand-new language.
On the other side, we can’t really declare Flutter as a total loser. There are far more advantages for adopting this cross-platform language that might outweigh the switching cost. The ruling? Simply too soon to tell. Dart might have a smaller switch pool (when talking Java engineers with a dash of passion form mobile).
However, since Dart is talking directly to a device, it might be a more feasible option for providers that release high-load apps with a cross-platform requirement.
Flutter vs React Native 2:1
In matters of supporters, the winner here is obvious. As a JavaScript-based Framework, React Native takes the lead. Simply because there are a ton of web developers that eat JS on their Peanut-Butter-Jelly sub, every single day. There are also lots of Java engineers that could (in theory) jump the Dart wagon.
Nonetheless, since the latter is quite a recent programming language, it’s adoption is not as wide as JS’s. It is to mention though… Dart is still growing, and there’s no say if React Native will keep holding the leader title for long. Just as an example, take a look at these developer interest metrics shared by stack overflow:
Flutter vs React Native: StackOverflow Queries
PC: https://insights.stackoverflow.com/trends?tags=react-native%2Cflutter
The architecture battle
What one lacks in popularity, it gains in performance. This statement is true, especially when comparing the technical architectures of Dart and React Native. After all, it is essential to any development team to acknowledge the internals of a particular framework… And take an informed decision when choosing one over the other.
As mentioned before, cross-platform frameworks rely heavily on app wrappers. In case of React Native, we’re talking about a JavaScript Bridge. This one, essentially compiles JS into native code at runtime. The cost lies within sacrificing some of the performance metrics in favor of a cross-platform environment.
Simply put, while more efficient than other cross-platform frameworks, React Native still needs an inside man for deeming access to the native party. Tho’ no one can guarantee its status as a mobile homie.
On the other side, Flutter’s Dart is the coolest new king on the block since it communicates directly to the device (compiles to machine code) via its Skia C++ engine. Essentially, since it has Material Design (for Android) and Cupertino (for iOS) elements built-in, it meets almost all the requirements of a native build without the required performance sacrifice.
Flutter vs React Native 2:2
Without anything else left to say here, it is obvious that Flutter takes the lead. After all, this guy wears the badge of “a true homie” for natively produced apps. It doesn’t really need anyone on the other end to get in.
Getting started
To determine a winner here, we’ll look at how easy it is to get started on any of the frameworks, weighing against ease of install and the available documentation as per both: Flutter and React Native.
You’d think that setting up a project in Xcode for React Native would be easy. After all, there is some info on the command line there. Withal, it won’t be enough to get it done. Particularly this is due to the fact that the documentation on React Native is quite scattered and to make matters worse, React Native’s “Getting Started” guide, assumes you’ve already got in place for delivering Android and iOS builds.
Anyways, if you’re a newbie, expect to spend some time researching all the prerequisites required for the initial setup and only after you’ve got everything set, you can create and run your project on an iOS simulator, by entering the following commands:
$ react-native init HelloWorldRN
$cd HelloWorldRN
$react-native run-ios
Now, here’s something you haven’t been expecting: for Android Setup, there is no guide whatsoever, so make sure your fingers are ready to Duck-Duck-Go instructions and setups provided by fellow React Native engineers that brewed Android apps before.
On the Flutter side, deploying your first project is more of a step-by-step procedure. The framework’s “Getting Started” guide is beautifully laid-out with instructions for both: Android and iOS environments.
Furthermore, if this is not enough, there’s also a CLI tool, called “Flutter Doctor” that can guide any developer through the entire setup, inspecting which tools are installed on your machine, delivering configuration instructions and even detecting which repositories are missing. In other words, they even have a babysitter for each and every developer desiring to build a Flutter app. There are no assumptions and once you’ve run the “Flutter Doctor” there is no doubt, you’re ready to go and create your first project within the CLI:
$ flutter create HelloWorldFL
$ cd HelloWorldFL
$ flutter run
Flutter vs React Native 3:2
With that in mind, It is widely clear who scored in this round: Flutter is clearly the winner, especially since it’s documentation is a pleasure to explore.
API Development and UI components
This relates a bit to the architecture penalty, where React Native fell behind Flutter. IF you’re building a cross-platform app, native component support is paramount. Without it, your cross-platform brew would simply feel like a poorly written native wannabe instead of delivering a true Android either iOS experience. Also, API access to native modules must be painless, otherwise you’ll see engineers running away even faster than Roberto Carlos.
On the React Native side, things are nice, but not as nice as you’d expect. The framework’s core relies heavily on third-party components delivering basic UI rendering and device access APIs. If you really want to build the next Uber or AirBnB, you’ll definitely have to browse through thousands of libraries, reviews, dependencies, before you’ll get everything you need to achieve a given scope.
While the variety is great, it will take some time to make sure everything works as intended. At EBS, we must say that relying too much on third-party components might be a deal breaker – so this one might actually count as a penalty on our end.
On the Flutter side, everything is a not upside-down. Instead of making use of third-party libraries, the framework delivers a rich in-built native component collection that is indeed bliss in matters of managing dependencies.
On top of the above, Flutter is bundled with navigation, access, device APIs, UI rendering, stateful management components and loads of libraries that are ready to use right here, right now. With its Cupertino and Material Design widgets provided on the go, any developer can render UIs on both Android and iOS with ease, without having to worry that a library or component is no longer supported or requires some third-party access.
Flutter vs React Native 4:2
Yet again, Flutter scores here, leaving React Native 2 Points behind.
Community
In IT, size does matter – at least when referred to the community. After all, a framework is doomed if there is no one there to share, learn and build on top of the original concept. If one seeks adoption, space where engineers can discuss bottlenecks and find solutions is preeminent.
Since its launch 2015, React Native has been doing pretty well at this chapter. There’s a huge virtual community on GitHub. On top of that, the framework’s fans and sponsors organize several meetups and conferences around the world.
For instance, if you’re an Eastern European developer with a keen taste for React Native, you can share, learn and meet-up with your idols at the React Native EU summit set for 5th to 6th of September 2019 in Warsaw. Otherwise, you can find similar events almost everywhere around the world. Heck, there’s a chance one takes place in your area.
On the Flutter side, despite the fact their virtual community is growing, there are fewer meet-ups to attend. Unless you’re able to get a golden ticket for Google IO or Flutter live – there is not much going on. Despite that, Flutter compensates with hundreds of virtual meetups and conferences. Though not as engaging as a real-life event, these still work but we’d definitely love to see more physical meetups across Europe.
Flutter vs React Native 4:3
We’ll have to give this goal to React Native as it seems closer to its hard-core fans.
Testing – how easily it’s done and how well it is supported
If you’re looking to build something bigger than a 6-view mobile app, you’ll definitely have to check this one out. Deciding on the appropriate testing framework is not a gimmick – on our end it is part of the entire development cycle.
Being able to receive interactive feedback on the code you’re writing is one of the most sought procedures across engineers since these can validate whatever you’re writing, making sure no basic bugs go through. If one is serious about its development cycle, being able to create UI, integration and unit testing for his/her build is no longer a luxury.
From the beginning, React Native falls way behind when talking about integration and testing. Its JS source alone can benefit of very few tools designed for this purpose. Nevertheless, there’s Jest, a tool that can be used for snapshot testing, but if you’re looking for something more than that – it is a bit of head-scratcher.
When it comes to integration or UI testing there is nothing officially supported to guarantee a lucrative testing environment. You’ll have to spend some time to find a fitting amongst third-party tools such as Detox or Appium witch are not supported but could somewhat replace some efforts to that matter.
In the Flutter land, things are widely brighter. There are tons of testing features at the integration, apps and even widget level. Furthermore – you’ll have a smooth ride here since everything is documented to the tiniest detail. If you can read documentation, you can set a proactive testing environment for your flutter app.
Flutter vs React Native 5:3
Clearly, React Native falls back again – leaving the gates open for Flutter’s score.
Application Publishing automation
When building a cross-platform app, releasing your builds to the respective stores can get trickier and in some instances, leave some bald spots on the engineer’s head. Basically, here, you’ll have to back-trace, initiate code-signing and in some cases, alter your initial setup just to get approved – let’s see how this works for both of these frameworks.
There is nothing in React Native’s documentation about automating deployment to respective stores (at least for iOS). Instead, you’re encouraged to publish an app manually, from within Xcode. Basically – you’ll have to sweat a little bit (if not more) to deploy your build to the App Store. Of course, you can always make use of Fastlane to deploy both: Android and iOS apps to respective stores. However, we’re comparing the “in the bundle” aspect here and at this, React Native gets yet another penalty.
With Flutter, it is the other way around. The swell documentation makes a build release as easy as 1, 2, 3. You can compile binaries using the CLI tools, test them before release and from this step further – all you really need is the documentation on hand. It almost feels like the designers of Flutter took note of the React Native’s shortcomings and built a better framework. If you want it all done via Fastlane, the documentation has instructions for that. You’re really getting your cake and eating it too.
Flutter vs React Native 6:3
It seems that React Native’s Gatekeeper misses the ball again, letting Flutter to score in glory.
The final Face-off: CI/CD and DevOps
If you want to release a future proof app, CI/CD is simply mandatory for your provider. No one likes applications that lack improvements based on feedback or have essential bugs. Continuous feedback and improvement within a dynamic development environment are key requirements – so let’s see how our opposing frameworks do here.
At this point, it is no longer a surprise that React Native’s documentation is (to put it politely) “as-it-is” and you’ll be right to assume there’s nothing regards CI/CD there. If you want CI/CD for your React Native app, Duck-Duck-GO is your friend. After several trial and error attempts and lots of reading we’ve achieved setting-up such an environment, but we cannot say it has been a bed of roses.
Yet again, Flutter is king regards CI/CD. There’s an entire section about it in its documentation alongside with several external links to best practices and painless DevOps, CI and CD. With its rich CLI interface, the CI/CD process itself is streamlined and if compared to doing the same for React Native, it is indeed child’s play.
Flutter vs React Native 7:3
Without any doubt, this one goes to Flutter, leaving React Native well behind on the scoreboard, 4 points behind.
Conclusion
This match is clearly a win for Flutter, however, there are lots of other matches where React Native would become a winner. On our end, React Native still works for particular business scopes and due to its seniority on the market we’re still working with this framework with all of the good, the bad and the ugly.
However, after releasing our first Flutter apps, we’re keen on switching, especially since Flutter builds seem to save a great deal of time, especially when enabling outstanding mobile experiences for our stakeholders.
Also, keep in mind that our match is hosted here and might be a bit different than yours – if you have some tickets available we’d love to join, listen on your scoring and perhaps learn something new from your Flutter vs React Native opinion. For that – leave us a comment and let’s keep this discussion open. After all – you decide if a rematch should ever take place.
