Flutter versus React Native: Mobile Application Frameworks Make Cross-Platform Development Possible

Modern mobile application development is often hampered by the options available for the platforms available. Will your application be intended for iOS, or Android? Both, plus desktop web browsers? What versions? What specific devices? How long do you intend to support the application, and what does this mean for the limitations and maintenance of your desired application? These questions and their answers have a serious effect on the potential for any application’s success in the marketplace, and the amount of effort that development teams have to put into creating and maintaining a successful application in the wild.

Let’s start with the basics. Essentially, if your application is intended for Apple’s iOS platform, the code could be written in Apple’s  Swift language. On the other hand, if your application will be offered to the world’s Android user base, then Java or Kotlin are the native languages usually targeted. You can see where this will cause major overheads and barriers to market uptake. Another way to think of it is like wanting to build a brick building, but having to build your own bricks first. Assuming that bricks are a standard item and that you know you can always get the right kind of bricks in sufficient quantities for your building project is usually a given. So, this is where development frameworks like Flutter and React Native come in. Depending upon which platform is chosen, quickly creating high-quality applications on virtually all popular platforms becomes a matter of staffing and education. Software development kits (SDKs) provide the virtual tool benches that application developers use to build the artifacts they hope will solve the problems their audiences need to solve.

Let’s break this down:

• Applications can be assessed by a few categories, related to their intended uses, audiences, and general applicability. 
• Uses could include universally available, which might mean portable, real-time access to the current state, and perhaps efficient use of platform characteristics (size and ease of use). 
• Platform might be an important factor if an application has a limited audience,  predominantly use a specific platform (this happens a lot around Windows, MacOS and Linux), and stakeholders with limited resources (people, time and/or money). 
• Expertise in the underlying tools is certainly a factor. Do you develop in the latest and greatest tools available, for future-proof benefits of having longer-lived application life-spans, at the risk of being unable to find sufficient developers who are competent and practiced with these new tools, and if so, can you afford to do it, based on the fiscal model that justifies the application’s creation? Or do you choose mature, well-adopted practices and tools, because it’s been a strong player for long enough to have spread the experience broadly? 
• Finding the appropriate strategy will be every creator’s initial challenge, because the future success or failure is first, the idea itself, and then, how you decide to turn it into reality. Will it work with the target platforms’ road-maps? For how long? How big is the audience? Will it make sense to build scalability early, or will it be re-imagined during its growth?

The first thing to note is that the choice involves belonging to either the Facebook camp (React Native) or the Google camp (Flutter). This probably doesn’t involve extreme risks, as neither organization is likely to dramatically shift direction on the core mission behind both frameworks. Delivering extremely robust, easily maintainable cross-platform applications, while keeping development costs, time-to-market, and application maintenance as low as possible. Let’s break down what that means for each stage of a project.

Choosing a Framework

The primary rationale for React Native appears to be its length of time on the marketplace, with React Native’s launch in 2015 and its predominance as pretty much the only cross-platform framework. This led to a steadily growing user-base, plus its reliance on JavaScript. This leadership was React’s (and major backer Facebook) race to lose. However, since 2017/2018, the meteoric entrance of Flutter, thanks to Google’s enthusiastic and deep-pocketed evangelism, has raised questions about the primacy of React. First to market usually works well, but it does require continuous feature introduction and workflow streamlining to stave off competitors who have had time to explore an incumbent’s weaknesses.

Times are changing and companies are directing their focus to making the mobile app the main access point to their product. The vast majority of users always carry a smartphone on them, allowing them to open any app with a single tap. 

Access to all the native phone functionalities—accelerometer, push notifications, or running in the background—is a huge advantage of mobile apps.

But there is no rose without a thorn. While you only need one development team with web technologies expertise to create a web app, the world of mobile apps is divided into 2 main operating systems: iOS and Android.

Each of these systems has a completely unique tech stack. Creating 2 separate apps that serve the same purpose, only on different platforms, may prove too costly—especially for startups or companies with a limited budget.”

— Kamil Rykowski, Full-Stack Developer & Adam Stempniak, Content Specialist. Published in STXnext.com

Implementation and Learning

Because React Native uses JavaScript, and due to its widespread base of skilled developers, there are more chances your team will get staffed up. On the other hand, there are issues in getting React Native’s components installed, mostly because the SDK’s authors assume that the JavaScript and command line skills will be clear, and reportedly the documentation leaves room for improvement. Flutter, which depends on a new language called Dart, created by Google to simplify development and make learning easier. An object-oriented language comparable to C++, Swift, Kotlin and Java, Dart compiles natively to ARM & Intel processors, or JavaScript for web application, and has built-in documentation to support developers transitioning from JavaScript/React Native. 

Development and Operations

There are some specific issues around the certification process for the two predominant application stores, Apple’s App Store and Google Play. Before any application can be posted to either store platform, the appropriate developer signature must be approved by the store, and embedded in the application before it will be publicly available to users.

Testing and Rollouts

There are differences in how developers work with each framework. Flutter is a more reactive platform, meaning that there is more freedom to respond to changes while in development. This means that changes to the end application are easier to adapt to with the Flutter framework, because the changes can be reloaded or re-rendered immediately, instead of having to rethink the overall structure. This usually means that a level of planning can move down to the practical level, allowing the people actually making the plan work can interact with details of the plan, reducing the to-and-fro of Context being translated into Conceptual, Logical and Physical design. When iterative improvements can be done with less effort, better designs are an inevitable end result.

Performance

Because Flutter’s underlying language, Dart, is specifically created to compile native machine language for the primary target hardware, namely ARM processors that almost all Android devices are built with, there are reportedly significant performance gains for Android apps compared to typical React Native/JavaScript-coded apps on the same platform. The goal of the React Native system is to be able to compile a React Native program for the target hardware. That’s the “Native” part of it; plugins or add-ons that convert the JavaScript of the framework into native code that runs exceptionally faster that a high-level language emulated down to machine code. If you think about how much faster everything goes when you aren’t converting from one language to another, the analogy works pretty well. Which isn’t to say that EVERY app created with Flutter outperforms the same app if it was built with React Native. It depends entirely on the functions envisioned for the app and how efficient the Native plugins convert the JavaScript of the developer’s work into efficient machine code to exceed the user’s expectations of what happens when that code runs. 

Dart substitutes a whole zoo of languages and frameworks developers ought to know today.”

— Andrew Manshin, CTO + Co-Founder

There’s one other factor that brings the question back to the HR department. When coding in JavaScript, it’s quite possible to create a module that can cause problems when it doesn’t know what to do next. With Dart, (and, as discussed in our blog about Kotlin vs. Java), the language itself is written so that a developer can’t create that situation unintentionally.

When it comes to performance, Flutter’s approach is quite different than that of React Native, or even NativeScript. Flutter’s application is compiled using arm C/C++ library so that it’s closer to machine language and gives better native performance. Not just the UI components are compiled, but the whole thing.

Dart is quite a performant language on its own, and many people believe that in terms of performance, Flutter has got the upper hand, although it’s hard to definitely judge as there are many factors involved in the performance.”

— Youssef Nader, Computer Engineering Student, Cairo University. Published in hacker.io

Conclusions

Depending on how long an app is expected to be deployed, it might be worth the initial overhead of building a Flutter-created app. Doing so would be betting on the Google-founded framework. If, on the other hand, people feel that the 3 year lead effort from Facebook’s funded React Native, it’s extensive ecosystem, and greater quantity of experienced developers gives a faster time to market, there will be use cases that make that a better option. There are conceptual, architectural differences to the two contenders that are worth thinking about, but the two main choices appear to be exerting effort now or extending that effort over the lifetime of the application. 

At AppMomos we’re always thinking about the future. Making sure that our products stand the test of time, with low maintenance costs and high usability, is at the forefront of our planning, design and development processes.