At Frontkom we love finding the right tools to solve problems for our clients. So when we find a tool that won’t just solve a problem, but most problems within an area, we get pretty excited. Because for us a tool is no better than the problem that it’s able to solve.
In this article I will show you how Flutter is one of those magical solutions which takes care of app development problems so much better than other tools.
1. Developing an app takes years
The first problem in making a mobile app is plain and simple: Your solution probably needs a lot of market feedback iterations to make any difference whatsoever in people’s daily lives. The app store was released by Apple in february of 2008, and there are innumerable apps on the market. Your first years in the market will probably be reevaluating your value proposition and doing a lot of changes.
Using Swift and Kotlin you will likely need to talk with two different teams, spend double the time in meetings, and end with an incoherent solution because each team will find it’s own path to the finish line.
If you choose React native, you will inherit around 30 years of old unplanned web technology.
Flutter is a brand new, just one dart language that solves all your business problems. Just one example is in file structures: If the developer starts with a file structure that ends up not making sense because of changing requirements, you can always break it down and rearrange, keeping stuff manageable and easy to maintain. Instead of ending up with spaghetti code, you’ll always be able to keep up with your app’s evolving business goals.
2. Developer availability
Investing is allocation of present resources to get gains in the future. Flutter passed React native activity on Stack Overflow in mid 2019, and now after two years has close to double the activity in there.
As an app developer, you want to have the highest possible number of active developers within your chosen framework, as this will inevitably lead to the most effective solutions being developed.
With Flutter you can not only be sure that you are picking the most productive framework, but also the framework that will have the biggest pool of developers in the future. The chances that your developers will be able to find the perfect plugin for your product are only increasing with time.
3. Device compatibility
The compatibility of your application with different devices can be measured in different ways. What Steve Jobs presented in 2007 as the iPhone was a screen with touch sensors, camera, speaker, microphone, gps, and wifi and sim card to access the internet.
To create app stores and play stores apple and google needed to create 3 main building blocks:
- High level UI layer
- High level Non UI Layer
- Low level c & c++ to support base implementations already in market like SQLite
As development for Android and iPhone always needed at least two programming languages, developers started to look at which UI components could be used to increase the number of lines of code shared between Android and iPhone.
Then some developers started to look at the high level UI layer and think about ways to code once, and run in both devices.
The problems with this webview approach are manyfold: First Apple may very well not even approve the app and even if they do, the performance will be much worse than native. 404s are also a concern.
To attack this problem, Xamarin created the first cross platform framework in 2011 that would use all the lists of UI components. So Xamarin, like React native today, would do the conversion between the codebase and the Android and the iPhone code. This was a better solution as it was at least possible to achieve a good product. But you would still have to test your development in both platforms all the time, or it may end in an inconsistent state.
So this is a resume of the web oriented and cross component oriented frameworks:
- Webview oriented:
- Apache cordova in 2009
- Ionic 2013
- High level UI oriented:
- Xamarin 2011
- React native 2015
The Flutter approach was completely different from the competitors, as Flutter was founded inside Google by a team that included Eric Seidel. He worked on the Chrome team for a while, and had one amazing idea: What if the app used the same GPU library that Chrome uses to work on desktop/mobile?
And now enter the Skia Canvas, which, like webview, is a single UI component that is responsible to render all the pixels on the screen of the phone. Yet with much faster render cycles as the instructions are in the language of the GPU.
In this way Flutter has solved the old problem of device compatibility. As the Skia Canvas is working in the GPU level, it doesn’t matter if you are on an Android or iPhone, Windows, MacOS, or Linux. If it has a GPU that supports Skia, the UI will work in the same way that in the device you tested. Like magic!