Container apps are the future

Post by 
Oliver Dixon
December 18, 2019

get asked the question by partners is whether or not they should choose native, hybrid, react-native, web, etc. I would have said React-native in 2018.

We took the strategic decision to rewrite and create all our new apps in Flutter. The reason? We found that React-native was extremely unreliable, especially on various Android manufacturers. We discovered that it will always be the way; due to vendor upgrades and skin changes.

So why 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 or vendor modifications (Android). Not only that but the performance and reliability is incredible, the quality of these components is even higher than the native equivalents in some cases.
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. Also with native you are writing it twice!

Native vs. Flutter
Native is bad.. React native is layers on top of 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 have 100’s of bugs. Libraries would be updated, and features would removed. There would be no change logs, or warnings for the developers.

Vanilla JS was a big issue for us. Many libraries didn’t support TypeScript. 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 overengineered in the React-native projects we handled. It went from a beautiful, elegant, simple store to a monstrous beast full of middleware, observables, and ‘epics’ (the worst thing ever). We saw apps that were 70-80% Redux code. 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; aka lost business, bad reviews, etc.

React-native also has a huge problem. It has to be on top of native platform changes. So when Google or Apple decides they want to change things around, it could potentially break your whole app.

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 many of the same issues with Flutter.

The big Android problem

Android phones in 2020
There are more than 14,000 Android devices. Many of which have unique bugs.

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. Some devices with React-Naive looked entirely different. Dialogs all over the place, different colours, forced fonts, random bugs because the manufactures development teams have changed core components of Android. The worse of these manufacturers is Samsung, the amount of platform bugs their devices have generated over the years has been colossal. This results in a poor, inconsistant app user experience across Android devices.

To rub salt into mobile developers’ time, 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.

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.

Wrap up

We really believe that Flutter is a great way to make apps, so far we've been using it for more than two years and it's been great!

If you'd like to read about a Flutter app we recently created you can do here.

If you're interested in developing any kind of software be that mobile apps, websites, games please get in touch.

Join Our

We never share your info. View our Privacy Policy
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Join Our Amazing
THere's More

Post you might also like

All Posts

Why Polydelic & Our Process

At Polydelic, we pride ourselves on writing high-quality applications and delivering them a record speed.

Why does software need maintanence?

We'll explain why software needs maintenance and what we do to reduce those costs.

The cost of hiring a bad developer is over $400k

Hiring a lousy developer can cripple your business; we'll example why.

Traditional CVs are as good as firepaper. How to hire a developer.

We discuss why CV's are a waste of time

Polydelic Coding guide

A short coding guide with some of the basic rules we apply in Polydelic