Our Experience with Flutter in Tokopedia
Cross platform native development has been the craze since the first launch of React Native back in 2015.
Tokopedia had its own history with React Native, having been used for several years on both iOS and Android apps, we soon found out that all the benefits came with the cost of poor performance which of course significantly impacted the user experience.
With the #FocusOnConsumer mindset, we eventually decided to sunset all React Native along with the hopes and dreams of having a single code base for both Android and iOS.
…Until Flutter was introduced.
The Project
For the Tokopedia START Summit 2022 event we wanted to enhance the participant experience from last year by creating an application on all platforms that will support participants by showing the agenda, sponsors, and ongoing sessions.
The mockup of the Application
The caveat? we only had approximately 3 weeks to develop, publish and announce to the participants, no doubt many questions arose from the team along the same topic of
“How do we deliver an application in less than a month on both Android and iOS in less than 3 weeks?”
Of course going back to a cross platform framework came into mind. Although learning our mistakes we had to ensure the technology and approach we used were all appropriate and scalable enough for future usage.
The Development Phase
The decision to go ahead with Flutter was because solved our problem of time and manpower, furthermore it was a very good investment. With dozens of new libraries appearing, growing community support, and continuously improved performance we foresaw that Flutter might have a better future. However we were soon faced with several challenges.
Challenge #1: Cross Team Collaboration
The team consisted of engineers from iOS, Android and Web Platform engineers. Each team had its own set of rules and standards and had to collaborate on the same codebase, this of course created some issues. For example; Some teams prefer to use squash & merge instead of merge commit when merging to the master branch or using rebasing instead of pulling when syncing branches.
We found out that it’s important to have an alignment in the beginning to set the same expectations amongst the engineers in the beginning and also over-communicate any issues they had.
Challenge #2: Project Scope & Collaboration with Product Managers
As mentioned before, Flutter is relatively new in Tokopedia. Because of this a feature that may only take 2 days to develop in normal conditions, might take an additional 2 days with a new technology. These 2 days act as a buffer because when working with a new technology engineers need time to research and of course debugging when stuff goes sideways.
It’s important to factor in those additional man days when creating your tech plan and ensure all stakeholders are aware so the team can adjust the scope & timeline accordingly.
Challenge #3: Deciding on a State Management
State management can be defined as a way to manage states, or various properties that are constantly changing inside of an application. Various platforms have different approaches when handling states, web engineers use state managers like React Context or Redux for React.js, Android Engineers use state holders and state hoisting for Jetpack, and iOS engineers use ObservedObjects for SwiftUI. With different paradigms, it was difficult to settle on solution.
First on foremost we all agreed that the approach had to be extendable, predictable and of course easy to learn. After several discussions we decided to use BLoC because it solved each of our concerns well:
Extendable
BLoC uses the concept of “business logics” that are abstract and can be used in multiple platforms and use cases. As a matter of fact, because of the abstraction and power of BLoC, we ended up using BLoC for most of our state management implementations.
Predictable
We always want to give the best experience, hence handling every edge case well. For example, what should the users see when there’s a query error? When there’s no internet connection? Or when the data is empty? The power of BLoC gives the powers to us engineers to do just that. BLoC leverages of “states” to control the UI. So we can set the UI to update when the state is “empty data”, “no internet connection”, and “query error”.
Easy to learn
BLoC uses the concept of events that are emitted to update the states of a UI. This approach feels familiar to both mobile and web engineers, making the learning curve faster for everyone.
Application Performance and Size
Performance is a main concern when using a cross platform framework based on previous experiences. Thankfully we did not see any significant performance degradations when using Flutter.
App Size
iOS → 29.5MB
Android → 7.9MB
Build Time
Average build time for our application took on average between 1m 30s until 2m to build
Conclusion
Overall our experience on working with Flutter was delightful, most of the challenges we faced was a results of everything except Flutter itself.
Of course this is all based on our conditions and environment so we recommend all engineers to research thoroughly before going fourth with a new technology like Flutter.
If you’d like to check out the application itself feel free to download it through these links:
