Bye React Native, welcome Flutter!

4 min readAug 14, 2018

From: https://italiancoders.it/flutter-sviluppo-mobile-cross-platform-firmato-google/

As CTO, it’s my role, among other things, keep our engineering resources aligned with the business interests of company. It includes taking care of the cost of our projects and products, and anyone who manages mobile apps development that should run on both Android and iOS knows that maintain two code bases is expansive due to the fact it’s necessary keep running two different code in different languages and frameworks, the cost of coders to build them, tests and so on.

A few months ago, we decide to stop developing with native resources such as Kotlin for Android, and Swift for iOS, which are very good languages, well documented and with great support, to migrate to React Native. Lots of companies back then were doing the same, and with good reasons: code once, export for both Android and iOS, sure, with a few specific adjustments for each platform, but Ok, code once, use on both.

Benefits I’d expect doing such decision? Let me say just two: reduction in maintenance cost and faster development time, as you just need to write the code once. Reality? It took more time to make some apps than before due to some errors and issues we’ve faced without a good support whether from documentation or friend devs. And sure, the most painful part of our experience 100% sure was debugging. A lot of problems have happened without we even know exactly what we’ve done. And the solution to some of them just came after a long search ‘till we found an opened GitHub issue where at the bottom someone was saying to whether remove the node_module directory and reinstall it or to restart the emulator.

Other interesting point that made us adopt React Native was the fact that our backend is 95% in Java Script with express and Node. So, once we were with only one main language in our teams, we thought it would bring to us advantages in communication during sprints as both back and frontend devs would share the same language know-how to fix bugs, handle issues, refactoring … but we din’t get that so well, and we’ve heard the same of some friend companies of us here in Maceio.

Some weeks ago, talking with some clients from Recife and São Paulo, they told me they had great success using the new google mobile framework, Flutter. Finished the meeting I started reading about it and soon it seemed a very powerful tool. But that time, before any decision I suggested to devs to just play with it, just for fun, and sure I did the same.

Six days then one of our devs wrote an article here at Medium explaining an architectural pattern used to build reactive apps, eight days then other one released one showing how we solved an internal frontend challenge to customize button background (See them at the bottom).

Summarizing, in two weeks the very team (yes, our backends were playing too) fell in love with Flutter.

It’s been one month since we start with Flutter and now we’ve got two big projects being made using flutter in frontend with absolute success, not only in the engineering perspective, but with client’s feedback, some of them engineering too.

Thus, at lest ‘till now, get Flutter as our frontend stack it’s been a great decision for absolutely sure:

it has been speeding up our development process;
It’s absolutely well documented;
It brings a great support from Google and the open source community;
It brings Dart as main programming language, a typed language, and as we can say by our own experiences: “languages without type” bring more problems than facilities.
It’s really a cross platform design framework, different from React Native, where you need to put some specif adjustments. Actually, it was a great surprise for all of us when we first saw an app running in iOS and Android with same interface and the same code.
Its debugging has no comparison at all with React Native, mainly if you use Android Studio or Intellij support. But even if you use other tools to build apps, like VSCode, if you get and error, you can see what is wrong, the line that the error is placed and then you can try to figure out what to do, instead of a red screen like that: