Since the release of Google’s Flutter framework for mobile app development, there has been a big hype around it in the developer community. We were asked by many of you:

“How is Flutter different / better than React Native, Felgo and other mobile app development frameworks?”


“What is the best mobile app framework today?”

So let’s get started to answer these questions.


What is new & different about Flutter?

Or as Wm Leeler, Developer Advocate & Senior Software Engineer at Google put it in this article - “What is revolutionary about Flutter”?

Note: We will reference the article by Wm quite extensively in this post, as it does a great job at explaining certain key features of Flutter.


Flutter’s Custom Renderer 

The Flutter core is based on C++ and uses OpenGL ES for rendering its content efficiently on iOS & Android. This is a key difference between the approach React Native, Angular/Ionic or others have chosen. Let’s dive in a bit deeper to find out why this is important and what advantages and disadvantages the different approaches have.


Differences between Native Rendering, Custom Rendering & WebView Rendering

In the following sections, you’ll learn about the 3 different types of rendering: web-based rendering, native rendering, and custom rendering. This is important to understand the differences between mobile app frameworks like Flutter, React Native and Cordova.


1. Web-based Rendering - for example, Cordova (Phonegap), Angular, Ionic

In early cross-platform mobile app development times, the content was rendered within a WebView, which is a browser window within an app. The most popular framework applying this approach was Phonegap, later renamed to Cordova.

As a developer, you would define for example a button, and this button then gets styled with CSS in a way so it looks like a native button on iOS and Android.


Javascript small bridge


The key disadvantages of this approach are:

  • The performance for WebViews varies a lot between smartphones as they rely internally on the WebView version used in the operating system version (e.g. Android 4.0 vs 6.0).
  • You are dependent on Apple (iOS) & Google (Android) to add features for & improve the performance of the WebView.
  • The supported features like certain CSS fields or the supported JavaScript standard vary depending on the web engine which is used (WebKit and Chromium are used in iOS & Android respectively). This, in turn, makes maintainability hard as you need to support multiple WebView browser versions and types, similar to the issues web developers are facing and getting nightmares from…Internet Explorer support you said?




  • The performance is a lot slower compared to native apps, because you run your code in a WebView running with JavaScript and also rendering your content via JavaScript/HTML commands for a web renderer. Web renderers were designed to display websites, multimedia content, etc., but not to efficiently render user interfaces & animations on mobile devices with limited hardware capabilities.

The most relevant disadvantage is performance, which was also the main reason why Facebook decided against a web-based approach for their own apps and rewrote their mobile apps native in 2012 for iOS & Android - with 2 separate code bases and separate teams.


2. Native Rendering - for example, React Native or NativeScript

Let’s again take Facebook as an example, looking at the history of how they develop their internal apps. This is a great indicator of the changes in the mobile app development landscape. After developing their apps natively for iOS & Android, the key disadvantage of native app development (long development time) led to the introduction of an own framework that was supposed to solve the key issue of web-based rendering (slow performance), and still allow working on a shared codebase for both platforms. This is why React Native was started at an internal Facebook Hackathon in 2013 and was released to the public as a Beta in January 2015.

React Native uses a very different approach to web-based rendering: Instead of rendering content in the WebView or the mobile web browser, the content is rendered with native OEM widgets provided by the platform. JavaScript is still used for the application logic to be able to re-use the same logic across platforms. The rendering, which is the most performance-sensitive part, is done with native components for this very reason: high performance.


Javascript vs Bridge


This gives you the huge benefit that your app looks and feels native because the elements shown on the screen are literally native.

However, there are also disadvantages to the “hybrid native rendering approach”:

  • An own UI needs to be written for iOS & Android separately. This also means the UI animations need to be developed separately, which results in two separate code branches, more effort to add new features, fix bugs, etc.
  • Creating customizable user interfaces with theming support is tricky with this approach, as you are limited by what the platform widgets provide in terms of styling.
  • Performance: whenever there is a change in the data to display, the app needs to compare the difference with its current state in JavaScript first, and if it detects a change, propagate this to the native view with a JavaScript Bridge. This is a performance bottleneck you can observe in React Native apps.

React Native tries to solve this issue with a virtual DOM approach to reduce the amount of data transferred between the logic and renderer, and also to limit redraws of the screen. It does a fairly good job at this, however, the key performance bottleneck still remains the data transferring across this “bridge” between JavaScript and the native platform.


3. Custom Rendering - for example, Flutter, Felgo & Qt

Flutter solves the disadvantages of hybrid native rendering with the following solution: 


Your App Vs. Platform



What are the differences between Flutter & React Native?

The rendering happens within a custom renderer, and the only required communication with the native platform is receiving input events or accessing native APIs like sensors. This provides a huge boost on performance because the cross-platform app needs no constant syncing with the native state.

You can also see this on the side-by-side comparison:


Custom Renderer, used in Flutter & Felgo

App vs. Widget tree


Native Renderer, used in React Native:

virtual tree



Flutter and React Native Differences

To summarize, the biggest difference between Flutter and React Native is the way in which the content is rendered on screen:

  • Flutter uses a custom renderer. This guarantees that your app will have the same layout on iOS and Android with a single source code. This also means it will not have a 100% native experience.
  • React Native requires you to develop a separate UI for iOS & Android. The UI will behave exactly like native widgets.


Why would I want to share layout code across iOS and Android?

The Flutter FAQ describes this pretty good:

"You can choose to implement different app layouts for iOS and Android. Developers are free to check the mobile OS at runtime and render different layouts, though we find this practice to be rare.

More and more, we see mobile app layouts and designs evolving to be more brand-driven and unified across platforms. This implies a strong motivation to share layout and UI code across iOS and Android.

The brand identity and customization of the app’s aesthetic design is now becoming more important than strictly adhering to traditional platform aesthetics. For example, app designs often require custom fonts, colors, shapes, motion, and more in order to clearly convey their brand identity.

We also see common layout patterns deployed across iOS and Android. For example, the “bottom nav bar” pattern can now be naturally found across iOS and Android. There seems to be a convergence of design ideas across mobile platforms."

We can only fully agree with this! In today’s market, a branded, custom UI is the way to go.

To prove this, here is a collection of apps that got awarded with Design awards:


Best Design

Source: Why Flutter doesn’t use OEM Widgets

You can see the similarities between platforms achieved with a custom UI.


When should you use Flutter vs React Native?

This question boils down to what your app’s requirements are. React Native’s biggest advantage is if you have a more “traditional” app that uses native elements with little styling or animation extensibilities. The perfect use cases are social media apps like Facebook itself or messaging apps like Slack or WhatsApp.

Flutter is great when you want to do a more modern UI, custom styling & animated user interfaces. Great examples for this are apps like Spotify or Airbnb (see above).

If you do not want to make a compromise between the two use cases and see them both important in current and future apps, then make sure to try Felgo as it is the only framework that supports both: custom rendered widgets and native rendered components.

So, as you can see, it strongly depends on which type of app you plan to make. The decision which app framework is best for your use case also depends on what the development experience in your team is like:

  • Development team experience: Which programming language does your team have the most experience with? See the language comparison in the next point to understand which framework is the best for whom.
  • Existing source code: Do you have existing source code that you plan to re-use? These are the programming languages supported by each tool, respectively:
    • JavaScript: Both React Native and Felgo support JS. Many libraries and components are available for JS.
    • Java/Dart: Flutter supports this cross-platform. There is limited availability of libraries & native SDK integrations for Dart as it is a much younger, less known and used programming language than C++ or JavaScript.
    • C++: Felgo has better C++ support than React thanks to the extended Qt framework capabilities and better C++ to scripting integration.
    • Native iOS code in Obj-C/Swift or native Android code in Java/Kotlin: all 3 frameworks support the integration of native iOS or Android code. Keep in mind that you will need to maintain this code separately per platform if you want to keep it.
  • Hiring new developers: It is easier to recruit JavaScript developers than C++ or Dart developers. The required time to learn a new framework should also be considered - Flutter and Felgo are significantly easier to learn & master than React Native.


Canva - Teamwork


The Flutter Hype - Why Flutter is NOT revolutionary

Flutter is not the only and not the first framework that embraces the approach of custom rendering. In fact, Felgo which is based on the Qt framework has been using this approach since 2012! Actually all game engines & game frameworks use this approach of a custom C++ based renderer, to be able to get the required performance for games.

Besides Flutter and Felgo, however, none of the existing gaming frameworks also focus on mobile app development. Initially, Felgo started as a games-only framework. However, the mobile app landscape started changing in a direction where fluid UI animations, customizable user interfaces, and extensible components got more important than “just” showing default native widgets. Interestingly, exactly these requirements are well supported in game frameworks, which is why it was a logical next step for Felgo to provide a common base for both game and app development use cases.

Yet, app developers not only need custom UI elements in their mobile apps but in many cases also require native-looking widgets, like a native button, input text field, native tab bars or a native navigation system for iOS & Android (which is mostly swipe-back functionality on iOS and a navigation drawer on Android).

Both use cases are combined in the Felgo SDK, available here for download. To support the trends mentioned above, we started developing the app components in Felgo in 2015 and since then focused most of our R&D in this area.


What are the differences between Flutter & Felgo?

The goals: Both Flutter and Felgo were designed to make modern mobile apps that require fluid UI animations and an outstanding user interface. Flutter’s components were designed to make UI development as fast as possible because it often takes the most time in the app development process. Similarly, Felgo uses QML - a reactive scripting language that can be combined with JavaScript & C++ – which was specifically designed from scratch with the goal to be good at one thing: UI development.

Where Flutter’s possibilities end with mobile app development, Felgo also allows to develop games, embedded platforms, desktop and web applications with the same SDK and mix these APIs in one app. Furthermore, Felgo allows rendering 3D content in your mobile app, which gets more and more important with the rise of 3D user interfaces. But also because visual effects like shader effects are gaining popularity in mobile app development to make your app stand out – all of these requirements are supported in Felgo.

Programming language: Flutter uses Dart, a Java extension by Google. Felgo uses QML for reactive (alias declarative) definition of UI elements and JavaScript or C++ to implement the application logic. QML extends JavaScript with type safety (similar to TypeScript) and reactive programming features – so-called property bindings in QML – to be more efficient with less code.

Supported platforms: Flutter supports iOS and Android. Felgo supports iOS and Android as well, and additionally the Desktop platforms Windows, Mac OS and Linux distributions like Ubuntu. Felgo also supports Linux based embedded platforms like the Raspberry Pi or Arduino. We are currently also working on adding an export function for the Web, which will allow you to share the same source code across all platforms.

Development Tools: In Flutter, you develop your app in Android Studio or Visual Studio Code. Felgo extends the Qt Creator IDE, which features a visual UI editor with drag-and-drop support for app components and side-by-side view of code and the visual editor.

Felgo also supports Live Reloading both on the Desktop for quick simulation of the UI on mobile. And also a mobile live reloading app that supports reloading the code you just saved in the IDE on your mobile phone. This reduces development time significantly, as you save the time of re-deploying the whole application every time. Hot reloading is also supported by Flutter. The benefit of Felgo is that you can simulate mobile UIs for different platforms on a desktop build, and even can change the platform style at runtime.

Compiled code & performance: Dart and thus Flutter uses a Java Virtual Machine (JVM) to compile your code ahead-of-time. Felgo uses the QML engine to compile the scripting code to C++ code at runtime. For publishing your app, you can enable ahead-of-time compilation with the Qt Quick Compiler: the QML code is then parsed ahead of time and C++ byte code is generated for it. In terms of performance, the compiled Java code runs slower than the generated C++ code, however, the JavaScript code for application logic used in QML is slower than Java code. That’s why we recommend developing performance-critical application code parts in C++, which yields the best performance.

For most apps, the application logic, however, will mainly contain requesting data from a web server and displaying this with the custom renderer. In this case application logic performance in JavaScript is sufficient. If you have real-time requirements with data that you are processing, like for example analyzing a video stream, this part should be done with C++ and by making an API for the scripting environment to notify for example when the processing is done. You can find example code for this scenario here.


C++ vs. Qml


Release Process: Flutter has been out of beta for a while now, but there is still little information available on how often new releases are planned per year, and how many releases break backwards compatibility. During the development of a mobile app, you want a stable framework which on the one hand is constantly being improved by fixing bugs, but on the other hand, it does not contain breaking changes that would require you to change your existing app and possibly add new bugs with that process. Angular and React Native are popular examples where the high release frequency causes issues for developers who do not want to update their main project yet, let’s hope Flutter does a better job there.

Felgo is based on the Qt framework, which has long-time-supported (LTS) releases that are guaranteed to receive bug fixes for 2 years. This allows you to choose if you want to keep your project on older Qt versions which still get bugs fixed and are guaranteed to stay API compatible (these two topics are the main difference here!). Or you can choose to update to the latest Qt version to use the newest features.


Feature Comparison Table Between Flutter, React Native & Felgo

This table aims to help find the best app development tool for your mobile app requirements:

Flutter, RN, Felgo Comparison Table


Test the new features now in the Felgo SDK. Download for free today!


Disadvantages of Felgo compared to Flutter

For a fair comparison, we’d also like to describe the cons Felgo (currently) has compared with Flutter.



This is the Flutter FAQ about licensing:

"Flutter includes two components: an engine that ships as a dynamically linked binary, and the Dart framework as a separate binary that the engine loads. The engine uses multiple software components with many dependencies; view the complete list here.

The framework is entirely self-contained and requires only one license.

In addition, any Dart packages you use may have their own license requirements."

This means you need to check the dependencies you are using in your project and adhere to this license. The respective license might be a no-go for your company, so please check carefully.

Felgo is developed closed source, however, its source code is available for commercial customers. The commercial licenses allow you to remove the splash screen, use all engine features and additionally provide an included set of support hours to help you finish your project faster or develop features you’d need, tailored to your project.

Felgo builds upon the Qt Framework and thus the same licensing terms apply like Qt. Qt is available in LGPL v3 and commercial licenses.

Both license types of Flutter and Felgo have valid pros and cons. It depends on your legal requirements which is the better to choose. If you have more questions about licensing, simply contact us here or click below.


Choose Your License


So what is the BEST Cross-Platform Mobile App Development Framework?

In my opinion, there is not a single “best app development framework”. It depends on many factors, which tool is the “best for you”. These are some considerations you should ask yourself:

  • Do you have an existing codebase you would like to reuse? If so, choose a tech that allows you to reuse your code. Specifically, the tool needs to support the same programming language that your existing codebase is written in.
  • Does your development team have a (positive) experience of releasing an app with a technology? If so, you will have a harder time to make them try another tool. You can find some valid arguments in the following list items.
  • What are the requirements of your app? This is the most important question. Each of the tools is great for a different kind of app. Should it have a custom UI or native UI? A mix of the two? See the feature table above for a recommendation.
  • Do you plan to bring new developers aboard? What are the programming languages your existing developers know?

So there is no single “best” solution for everything. It really depends on your use case. For companies relying on stability and who value a dedicated enterprise-support level, the only option is Felgo & Qt, which is also the reason why so many of the Fortune 500 companies rely on it.



More Relevant App Development Resources


More Posts Like This

How to Make Cross-Platform Mobile Apps with Qt – Felgo Apps


Release 2.16.0: iPhone X Support and Runtime Screen Orientation Changes


How to Expose a Qt C++ Class with Signals and Slots to QML
How to Expose a Qt C++ Class with Signals and Slots to QML