Why Flutter will help scale QuintoAndar’s Mobile presence

Augusto Souza
Blog Técnico QuintoAndar
10 min readJun 14, 2021

Recently, QuintoAndar decided to use Flutter as the standard framework for mobile development! We will train our engineers internally in this technology, hire others from the market with this skill, launch more and more features using it, and rewrite others so we can have a more maintainable mobile codebase.

In this blog post, I will tell you why we made this decision and how we are building an environment in which we can deliver better quality apps without slowing our pace.

Our history in Android

QuintoAndar has a culture of full-stack development, which made us invest in Android’s Trusted Web Activity (TWA) to deliver our Android app to the Play Store as soon as Google released it in 2019. This replaced our native Java Android app. At that time, this was a great decision to make, since we were a small team, and maintaining frontends for web, Android and iOS was nearly impossible!

When we look at our plans for scaling our business by delivering products to the market at a fast pace, this was a great decision. For instance, we were able to start in a new business vertical — Real Estate Sales — by changing every aspect of our user-facing and back-office product in just 3 months!

But, we never stopped to focus in the satisfaction of our clients. This made us see that 27% of our unhappy customers were complaining in the Play Store about issues regarding their experience. Reviews like the one below were often seen:

Review of a user in the play store telling other users our app is just a website wrapper

For this reason, we discovered that TWA was great for release and product deliver since a push to the master branch and a CI build was all we need to deploy a new version of our Android users, but we still needed to make those 27% of our users happier.

Our history in iOS

iOS has always been an important platform to QuintoAndar. Our app is mainly written in Swift and we used to have a small focused team of engineers responsible for adding features and maintaining our Owners and Tenants/Buyers apps for the Apple Platform. The iOS users are happy with our product for most of their experiences, our app’s ratings are 4.5 and 4.8 (respectively) for a long time now.

However, we had a different problem with this platform: after the growth of the company we had more than 30 squads developing features for our PWAs and Backends and only 1 team working with our iOS apps. This made us realize that to continue to deliver the hottest features to our iOS users we needed to have a bigger team, or have iOS engineers not centralized in one squad or to democratize the mobile development at QuintoAndar. The Apple development environment is not an easy one to get into, how many iOS Engineers do you know that work with React, Android or Backend too, for instance?

Fluxogram showing we had more than 30 squads working in web and just 1 working with iOS

Enter cross app frameworks (aka React native VS Flutter)

Recapping the problems we had with mobile development:

  1. In Android, we could have a better user experience (27% of our reviewers asked for a native mobile app)
  2. In iOS, we would start to have problems maintaining the apps up to date when compared to our PWAs

We knew that hiring Android engineers to rebuild our app in Kotlin or more iOS engineers might solve our problems. But, we would need more specializations, and the proximity of the engineering team with the product development team in which the features have been defined would suffer. The ideal scenario was to have mobile engineers just like we have full stack engineers: not specialized in just one technology, but with Kotlin and Swift this wasn’t going to be easy.

Also, we were seeing some interesting usage of cross app framework such as React Native or Flutter in the industry, some material that took our attention:

If one of these worked for our use case, we could have the possibility to solve all problems described above 🎉

So, we decided to experiment with those technologies, we started studying and developing Proofs of Concept with React Native and Flutter. These were the two main stacks we thought were worth investing in. The features selected to be developed in our PoC were the search list and map, with these two we thought we could evaluate both frameworks in some aspects with different weights for each one related to how we see the aspect for QuintoAndar’s use case. The aspects were:

  • Perfomance
  • Community / Ecosystem
  • External hiring
  • Internal hiring (how easy is it to teach another internal engineer to develop with the framework?)
  • Code reuse
  • Automated tests
  • CI / CD
  • Modularization
  • Debugging
  • Native look and feel
  • Animations
  • Web integration (we knew we would still need to deliver some features with webviews)

We had only one engineer (Wesley Costa) and one manager (me) during this phase of the project, so we evaluated React Native and Flutter in the above aspects before and after the PoCs. This way, we could measure any changes in our perception. This change really happened, in the beginning we thought RN would fit better in QuintoAndar’s use case, but after working a little with each one, Flutter seemed like a better decision (of which we do not regret!). The following screenshot is from our spreadsheet used internally to register our perceptions:

React Native and Flutter comparison matrix

After, deciding on betting in Flutter we still needed to deliver mobile products with it to prove our point.

The road to 4.5 stars in the Play Store

We decided to rewrite the most important features in Flutter and release a new Android app to the Play Store with the native look and feel and perfomance we knew Flutter could deliver. We wanted to compare the Flutter version with the TWA version, so we used Play Store Staged Rollout to achieve this. Also, we didn’t want to change the design since this could influence the results we might have.

For features addressed to users with higher intent in using our service, such as offers, visit scheduling, contract signing, etc., we decided to maintain the experience of usage inside webviews. We couldn’t use TWA since data exchange between the native part (in dart) and the web part is really difficult with TWAs, as the official documentation tells:

The host app doesn’t have direct access to web content in a Trusted Web Activity or any other kind of web state, like cookies and localStorage. Nevertheless, you can coordinate with the web content by passing data to and from the page in URLs (e.g. through query parameteres and intent URIs.)

In parallel, we needed to establish a review analysis process in which we could carefully look at what our users were complaining about to make sure that we would not receive reviews of the category “this is just a website” anymore. The integration of a tool called appbot.co with our slack made this possible. We had engineers, QA and customer experience specialists looking carefully at all reviews customers post in the stores.

With all these aspects under construction while we were also developing our first Flutter app, we could release to 50% of our user base. By checking the reviews and rating closely we could get confident that releasing it to 100% would make our ratings better. This process took us 5 months but we were able to change the rating from 3.8 (TWA version) to 4.5 (Flutter version), which is the rating we have at this moment in the Play Store.

Screenshot of the Play Store showing our app with 4.5 stars

Since February 2021, when we got confident in releasing the Flutter version to the whole user base, our rating only gets better 📈

Ok, but how can we use Flutter on iOS now?

One of our dreams with Flutter was to effectively share parts of our application between our existing iOS and Android apps, so we could offload the ownership of those parts of the app with the squads focused on that part of the user journey. For instance: QuintoAndar negotiation flow — our applications that help you make offers and negotiate with the current owner of the house you want to live in — is big enough to be a startup on its own. We need to receive offers from tenants and, depending on some business rules, make it appear to the property owner. After that, we need to perform credit analysis, ask both parties to send their documents, validate the documents in our back-office and send a contract back to them to be signed. And this is a single part of our application. With 30+ other teams working on the web and a single one on Mobile, we would never catch up. But the main issue is that this is not the way we like to work. We like to give teams the autonomy to experiment and continuously provide value to our users in the best way possible. We avoid “execution-only” teams, and our Mobile team was at risk of working in this way if we were always porting features.

Enters Flutter, and we see a new world of possibilities: maybe we could create portions of the app as packages shared between Android and iOS and make it easier for teams to own their portions of our mobile apps as well. 🤔

So we decide on using a small feature as a Proof of Concept: the User Onboarding Screens

Shared onboarding screens

The reasons for choosing this portion of the app to be our first shared package were:

  • Non existent feature in Android at that moment
  • Every new iOS user would use, so we could evaluate perfomance with real users
  • There were no other teams at QuintoAndar working on it, so we could work in a more safe environment for tests

We have learned a lot during this process of releasing our shared Flutter version of the onboarding on how to work with packages in Flutter for iOS, but this is a subject to be described in more details in another post 👀

Now, it is time to scale! Oh wait, where are our Flutter developers?

This is a major problem for companies using new technology such as Flutter. During the reconstruction of our Android app and our Onboarding screens for iOS, we learned that Flutter is not hard to learn for those coming from iOS or React.

But we needed to scale, so we decided to invest in internal training and documentation. Documenting and investing in standardization since the beginning was crucial. Flutter is easy to learn and has great Developer Experience. So teaching Flutter wasn’t our focus. Our focus was teaching people how to use Flutter at QuintoAndar.

Rolling out this plan was a 3 step process:

  1. Getting people to do the training: Collaborating and talking with Product Managers and Engineering Managers in strategic teams to get hours from engineers in their team exclusively dedicated to learning Flutter. We designed the program in a way it wouldn’t disrupt the roadmaps of the teams to make this possible
  2. Curating content and creating a mentoring program: Our most experienced engineers both in Flutter and Mobile development curated content based on objectivity and how critical it was for people with previous knowledge in engineering get a good hold of Flutter. Those engineers were also appointed as mentors for people who are in the training program.
  3. Planning and breaking down projects: We dedicated time to find good projects that would serve as hands-on learning opportunities while also providing value to the company. Guided execution of these projects is the bulk of our training program. We believe a lot in learning while doing here at QuintoAndar.

In a future post, we are planning on describing in details how we organized this internal training, stay tuned 👀

So, QuintoAndar’s frontend future is Flutter now?

We are a company known for its great knowledge in Progressive Web Apps, and React. We have lots of user-facing and back-office products written in these technologies, and we will not only maintain, but continue to evolve. Those will be key touchpoints and platforms for our customers and internal users. The web is a major platform for us and will continue to be. Our marketplace and products need to reach as wide as possible. Expanding and creating Mobile Apps is a way of giving our customers a great cross-platform experience that engages and reaches them in the right moments and in the right way. We will use each platform for what it does best.

We now know Flutter will be the future of QuintoAndar’s mobile apps and are investing heavily in training and building state-of-the-art knowledge here. Join us in building amazing apps on the Company that will be the go-to destination for housing globally 🚀 Let us know in your application you want to work with Flutter 😉

Thank you for reading 💙. More content about Flutter will be posted in the near future, stay tuned.

--

--