get asked the question by clients and leads whether or not they should choose native or hybrid. Last year I would have said React-native, something Polydelic supported for three years. React-native being a hybrid solution.
This year we took the strategic decision to create all our apps with Flutter. The reason? We were sick of breaking changes introduced not only by the platforms iOS and Android but by the React Native team. Almost 20% of our time was configuring and updating our React-native apps and trying to get 3rd party libraries to work. It was a colossal waste of money.
Enter Flutter. Flutter creates apps in a container. All the components are built from the ground up. You can get ‘native’ feeling components that don’t break with significant platform upgrades. Not only that but the performance and reliability is incredible, the quality of these components is even higher than the native equivalents.
Game engines have used this technique for years.
Native frameworks are old
And with that comes lots of bugs, legacy code, and much more that developers have to struggle with daily. Native app projects, on average, have 3-4x the code to achieve the same thing as React-native or Flutter projects. Looking at some recent app delivery tests, we saw that using Flutter; we could get apps to market on both platforms with 11-15x times less manpower than native and 3-5x less then React-native.
React-native: A poor choice for serious app developers.
When we first used React-native, it was a refreshing way to create mobile apps. Using TypeScript, you could easily manage medium to large-sized apps with 30k+ lines of code, refactoring support and silly errors were easy to avoid.
But what we found over the years was that many of the 3rd party libraries and even the React-native libraries had abysmal support or were just full of 100’s of bugs for years. Libraries would be updated, and features would removed. There would be no update information or warnings for the developers. For example, the main FB login library removed the login button but still kept the component shell resulting in FB login failing silently; what on earth!
Vanilla JS was a big issue for us. Many libraries didn’t support TypeScript (A stupid choice in 2017-2018). Some of the projects we took over were written in VanillaJS with no sign of data models, component types, etc. They were a nightmare to maintain or develop on.
Redux (A away to store data inside the app) was abused during this period. It went from a beautiful, elegant, simple store to a monstrous beast full of middleware, observables, and ‘epics’ (literally the dumbest thing ever). We saw apps that were 70-80% Redux code and the rest being services, UI, and helpers. Something was seriously wrong. On top of that, they were not using types inside the stores so it became a hellish landscape for developers to navigate and of course many bugs and crashes would occur because of this.
React-native also has a huge problem. It has to be on top of native platform changes. One coming soon, for example, was AndroidX. Google renamed all their packages because why not? Costing billions of dollars around the world to make these fixes.
Another example is the constant Swift breaking changes and Xcode updates. Another one coming soon is SwiftUI, Apple will start shifting towards this, React-native team and 3rd party developers will need to put in a lot of work to keep on top of this. You don’t have any of these issues with Flutter.
The big Android problem
At one of my old workplaces, we had a device lab of Android devices, around 20 devices. Before each significant release, we’d have a team of quality assurance personnel test each device. I can tell you now manufacturers screwed Android. Some devices with React-Naive looked entirely different. Dialogs all over the place, different colours, forced fonts, random bugs because their development teams have changed core components with no need (Once HTC changed a long to an int, crazy). The worse of these manufacturers is Samsung, the amount of platform bugs their devices have generated over the years has been colossal.
To rub salt into mobile developers’ time (I made that expression up), Android only generates a tiny portion of the revenue for mobile apps. Android users don’t buy any apps or in-app purchases, unlike the iOS alternatives. So not only are you wasting time with these manufactures you’re also taking more time then iOS to develop the same apps with a lower revenue; see the big problem here.
On Flutter, we encounter none of these issues. Since all the components are containerized, the UI is displayed using their engine. You can guarantee that the devices will function the same on every Android device out there while being ultra performant and emulating good native practices. Also, being the same code base for both platforms, there are simply no worries. Time is saved for quality assurance departments and developers alike.
If you'd like to read about a Flutter app we recently created you can do here.
I could write a book on this subject, here I’ve gone over some main points. We hope that you have enjoyed reading this. If you have tips or changes for us, please contact us using the contact page or leave a comment.
If you're interested in developing any kind of software be that mobile apps, websites, games please get in touch.