Why Startups Should Use Flutter to Build Mobile Apps
You as the startup cofounder only have so much mobile front end dev hours to spend to get a statistically important piece of market share and have to spread it to two different mobile platforms ios and android. You heard about React and about FB React Native and Google’s Flutter but which one is the true React Framework to use?
The React term comes from Facebook’s React js library project. Many think state management, and routing is what React is. Let me explain the iOS vs Android problem and why that is not so.
In Pre-React land both Apple and Google have different pre-react approaches to getting UI nodes small enough to manage state changes. Google came up with a invention called fragments to break down the bloated activity. And, Apple has something slightly different.
But, the key problem performance wise and design wise is not what one thinks. On the Android side we spend considerable time fine-tuning animated transitions and the RecycleView to get back up to 60 frames per second by dumbing down the animated transitions. ANd, than we face either dumbing down the iOS port or having two different UX things one for iOS and one for Android. Nothing kills upward MAU climbs on Android device user market like having it worse than the iOS port.
FB ReactNative originally started to put some portion of React into the native OS widgets. But, guess what? ReactNative on Android is not ReactNative.Without the UI node manipulation ReactNative is actually ReactLiteNative. Oh but it gets worse.
The difference between iOS and Android is that Android uses a Dalvik VM and java or java-kotlin. Despite having multiple GPU cores the animated transitions get messed up due to the rest of the UI on android running under java and not executed as C++. In 2015, Android had C++ bindings for all the OS widgets and Facebook rather than do the work punted and did not bind to the C++ OS widgets.
Now contrast this with Google’s Flutter. It has not just state, routing, and platform api manipulation but the actual core react concept of manipulating what passes for the DOM in non HTML mobile apps, ie the actual UI node.
What does this mean even though Dart VM as a C++ component of Flutter is single threaded? Dart supports the full Unix Thread<event and isolate model. Animated transitions run on a different GPU thread not the main UI cpu thread. The magic happens because we can use the functional hooks of Flutter-Dart combination to selectively render only the state changing UI node as a stateful widget.
Everyone focused on some simple tests by beginning Flutter devs who used Flutter in default mode and did not separate out the state changing UI node as its own separate widget separated out from rest of the UI nodes which should be their own widgets. So of course the results of their testing showed Facebook ReactNative performing a little better on Android. But, that was not the core problem.
The core problem was the getting 60 frames per second in the animated transitions EQUALLY for iOS and Android. AND, the major way to do that is to make each UI node have the react hooks to manipulate it when state changes through a light widget library like Flutter uses.
Now to be fair to Facebook, they did get rid of the backporting to previous OS versions stuff indirectly by forcing everyone to use javascript to interact with OS widgets. But that is only one half of the heavy added dev hours cost of the android java VM approach compared to iOS. Decoupling the UI from OS widgets and making it full react to be manipulated is the key to why this solution works so well.
Imagine this, take the estimate for building a native iOS app. Halve-it, that is your dev time hours for building a flutter app that runs on iOS and Android. No extra hours on back-porting for android and no dumbing down the iOS transitions to match android.
Get with the what the cool kids are using, the real React framework for mobile..Google’s Flutter Application Framework.
You can follow me via links at my homepage
