If you are hesitating about Flutter and don’t know if this technology is a credible choice for your product follow our article on The State of Flutter in 2022.
After reading this article you will learn:
It’s been two years since we started the development of our first commercial application in Flutter at LeanCode in July 2018. When I first learned about Flutter, although it was promising, I remained skeptical, primarily because of the negative experience from our recent investment into Xamarin.
Our development team is always excited about new technologies, and that was also the case there. They wanted to use Flutter in our new project. We agreed, however, we challenged them and asked for proof of how this could bring real value to the client.
It was an agricultural project dealing with herd management. There is one interesting artifact, typical for this industry, which is widely used by the breeders to calculate the demand for the barns and our team felt that this is a great insight from the UX perspective.
Within two days, they proudly showed the Proof of Concept, demonstrating how easy it is to build an animated wheel giving you a great and smooth experience. Eventually, this has evolved into full-scale animation, which you can see here:
With this delighter, I was convinced that Flutter is worth experimenting with.
Initially, we didn’t want to commit 100% to Flutter, so we kept the React Native projects parallel. When faced with writing our first implementations of Google Maps without official support from the Flutter team, I felt that this pessimism was justified. You can learn more about the experience of writing this first commercial application in Flutter and related difficulties by reading our case study.
Eventually, we delivered a relatively simple application with less than 40 views and costs below 500 hours of Flutter development.
Once we’ve delivered this first application and collected a five-star review from our client, we thought we should start recommending Flutter more actively to our clients since the beginning of 2019. From May 2019, we decided that Flutter will be our no.1 choice for mobile technologies, and we will cease our involvement in developing apps on different frameworks.
Since then, we’ve delivered more than ten mobile products in Flutter and dozens of MVPs/PoCs. Now, it’s time to conclude.
And we are not talking here about the theoretical approach, although this is interesting (find the paper by Bran De Connick). We had a unique chance to rewrite the apps from both Xamarin (client-facing mobile app) and ReactJS (restaurant manager facing web app), and the results were comparable.
It took us 67% of the time compared to Xamarin (667h vs. 987h) and 69% of the time needed to create the app with ReactJS (486h vs. 704h) for the very same scope using the same API on a backend side.
Stop and think about those numbers for a moment. It is the ultimate answer to how to build the mobile application quicker and cheaper.
With the economic downturn, delivering new digital products on time and within budget has never been more important. It can also mean that you can provide a 50% bigger backlog for the very same budget. Imagine yourself as a product owner working on the priorities for your development team, being able to move the budget barrier 50% further.
This will give a significant boost to both the creativity of your team and the quality of the work they are delivering. For a detailed analysis of the GastroJob case, look at our talk at Flutter Europe Conference or check our case study.
90% of our code is not written twice for both native platforms. 90% of the time is saved compared to native app development, and plenty of creativity is released due to the coherence and team being united around one goal instead of being divided into two native streams. Beyond sharing the business logic and user experience, we can use plenty of ready-to-go libraries, which bring additional benefits.
Firstly, they can speed up the development process by providing commonly used logic for many different things used within the app (e.g., communication with the server (HTTP client), push notifications, secure storage, databases, animations, etc.).
Secondly, it is easier to integrate with many popular services (e.g., Firebase, Maps, Payments, Social Login, Analytics, Crash Reporting Services, etc.). Therefore you have to write code twice (separately for iOS and Android) only if you’re writing custom platform-specific code. Yet, even then, bridging between Dart and native code is relatively easy, which is explained later in this article.
What is more, there are even more considerable savings when considering the quality factor, which makes the app cheaper also to maintain in the long run. As a matter of fact, it has inspired us to investigate all projects built in Xamarin, React Native and Flutter to search for the pattern and what we have discovered is that
Flutter projects typically need 8–10% of the time spent on bugs in comparison to React Native with the range 7–14% and Xamarin 11–23%
Something clicks on the cooperation between UX/UI Designers and Developers during the Flutter projects. It might be because they don’t need to make this tedious native adaptation and free their creativity.
Yet, I would expect the same from the React Native team experience, which is not the case. When we dug a little deeper, we discovered that Flutter brings pure joy for devs who can write beautiful interfaces, which previously were associated with an extra burden that slowed down the pace.
Therefore, they were more willing to cooperate, and we’ve observed that the pair programming sessions started with designers doing the live experiments hand-in-hand with devs. After several such interactions, thanks to the robust theming engine, teams were able to come up with an adaptable design language for the app.
It not only looked great in Figma or Adobe XD but also gave the best possible user experience and the feeling of coherence and proper design order. It's also interesting how this coherence is present over the lifetime of the project.
Previously when UX/UI Designers reviewed the product during the demo session, they had most of their comments at the end of the project, changing their minds or simplifying things after the hands-on experience. What is unique about Flutter is that at the end of the project, the involvement of designers is completely fading away, as they did their job early in the beginning during design loops of trials and errors.
It also means that the refinement of subsequent sprints takes less time, and this continuous cooperation is reflected in the stable scrum pace of the next releases.
Not only is it easy to implement some static views in Flutter, but it also provides excellent new opportunities when it comes to animations. It brings this UX-DEVs cooperation to another level making nice transition effects accessible as never before. So far, that was typical only for the big-budget projects.
Nowadays, thanks to Flutter, this is accessible to all developers. It happens because Flutter renders on bare metal, directly on the canvas with complete control over the drawing. It enables us to create pixel-perfect images on all platforms without additional, conditional formatting from another cross-platform framework.
For example, when drawing with React Native, you are based on the default views, which can alter the appearance of your new controls. Therefore, building a smelly code is platform-dependent and directly in contradiction to the approach that the shared code should not take into the platform where it is deployed.
This is worth considering when facing the PWA business choice, proving how easy it is to add the shortcut on your phone to save the website as if it was an app. Let’s not comment on the user experience, but only on the burden of downloading the app. Yes, this is not effortless in both cases.
According to the SimiCart Blog, the best PWA websites require users to download from 4.9MB to 11.6MB on loading. It is far lower than the average size of our Xamarin apps (which is 25MB) and even lower than the average for our React Native apps (32MB).
However, it is still very close to the Flutter average, which is 11MB with the range of 9–14MB for all our Flutter apps (pay attention that those numbers are not directly comparable, though they highlight the pattern). You have to admit this (11MB) is extremely low for the native application experience, for the smooth look and feel, rapid reactions, and all services typical of native apps like push notifications, etc.
It means that there are no barriers for users to download the app and start using it as efficiently as possible with all plugins and integrations. It also means that apps are more performant because they can execute similar tasks with minor code.
This boosts performance and translates directly into those milliseconds that give you a quicker experience in cold loading of an app, animations, CPU, and memory usage than other cross-platform frameworks (Flutter can provide a better cold app start even in comparison to Swift/Kotlin native apps).
What is great about Flutter is that the mobile team more eagerly goes down to the native code and writes some Kotlin/Swift packages to have complete control over the native implementation. For example, it was not the case in Xamarin, where the final code was generated in an isolated black box.
Bridges to the native code are also more powerful because they are completely transparent and therefore more friendly for developers who have transferred from the native environments.
This approach makes it relatively easy to implement specific features like local payment providers or some niche complex library. What is more, even advanced features requiring biometric algorithms for face recognition or fingerprint check are smoothly running on Flutter, as showcased in the banking app developed by ING for Business in Flutter presented during Flutter Warsaw Meetup by Jakub Biliński.
Before the client decides to sign the contract for the whole project, we can build the smallest possible app that answers the most critical business or technical question. This is the point where we cannot overestimate Flutter's capabilities. Every time we are timeboxing such initiatives to two days of development, trying to find out what can be achievable in such a short period. So far, we have been experimenting with various PoCs ranging from AR-supported image detection systems (below),
through whiteboard drawings and advanced animations.
Building a rapid PoC not only enables us to showcase the speed of development but also helps us to provide more accurate estimates for the final project.
From the perspective of building the internal team, Flutter proved to be a good choice. Initially, there were few Flutter developers because nobody had professional experience. Yet, what was different in comparison to, for example, Xamarin, where developers had a C# background, in the case of Flutter, all candidates were already mobile developers transferring from the native, mainly Android, background.
As Flutter became more popular - thanks to the very active community that organizes regular meetups and webinars - the pool of available candidates grew exponentially. Nowadays, a substantial number of professionals are looking for a job in Flutter projects and are willing to change sides after years of native app development.
Thanks to the well-documented Flutter code and the availability of additional libraries driven by the community, it is relatively easy to make such a transfer. Therefore some companies, that previously had their independent mobile teams are investing in aligning them around Flutter.
At LeanCode, we even organized Flutter Bootcamps - three-day-long training programs at the lakeside - to give hands-on experience and select the best candidates for the intensive, two-month-long study program. Learning Flutter was accompanied by doing some non-commercial projects.
We were surprised to notice that after 9-weeks of training, developers were ready to work side-by-side with their colleagues who started coding in Flutter from the early days. Such a short learning cycle proves that switching from the native app to Flutter from the business owner's perspective is not a revolution but an evolution in which their internal team can take an important part.
Making the right decision regarding your technology stack can have a lasting impact on your business and personal career. Yet, rarely is the choice so simple. Flutter has already become an unstoppable movement, a force to be reckoned with. It is still growing and expanding towards very conservative industries with extremely high-quality standards like banking or insurance (with examples like NuBank, ING, and AXA, to name a few).
Suppose you consider that this happens even before Flutter for Web or Flutter for Desktop are released in a production phase. This shows that Flutter for mobile is delivering enough value to compete in this very advanced market. Whatever industry you are working for, the times for early adopters are gone, and we will soon witness the arrival of more and more mature players entering the Flutter ecosystem.
I hope this will allow us to share the lessons learned from those implementations in next year's summary after making another ten great apps in Flutter.
4.94 / 5 Based on 17 reviews