Flutter at OY! Indonesia: Migration Strategy and Architecture

Published in

OY! Indonesia

7 min readJun 4, 2020

This article looks at how we migrate from Native to Hybrid (Flutter) and the resulting architecture that we implemented at OY.

There are two possible ways when migrating to Flutter from native:

Flutter as an incremental approach
Completely redesigning both iOS and Android

The first case is you have two apps written in their native languages and you want to add a new feature. Well, you can use all of your existing native code while writing your new features in Flutter. Yes, you can communicate native code with Flutter using Flutter Platform (known as Platform-Channel).

Let us consider the last case, you have both iOS and Android app and you need to completely redesign your current apps. Using this cross platform development tool, you can cut your development resources in half, since you only need one mobile and QA team, instead of two. This can free up your second resource team for other projects. It means you can have a 50% savings in resources over using traditional native approach. Performance and code size are on par with native. Even though we agree that native performance was unbeaten by any mobile cross-platform development tool (until this article is written). The only downside is the requirement to learn a new programming language, Dart.

Bold Decision

After we done with the research. We decided not to migrate to Flutter incrementally, but instead we will completely redesigning both iOS and Android app. Why? Wouldn’t it will be blocking our product progress and stopping us to add new feature (known as Feature Freeze)? Of course, it’s a trade-off. For us it’s okay to slow down. In fact, it take us 2 whole months to switching from native to Flutter until store submission with our single digit team.

It’s essential to slow down to regain more energy, so we can go faster, better, and more effectively as we work towards achieving bigger goals.

Coincidentally, some of you guys might know that we are transform OY! from chatting to p2p payment application. It means, we are going to wipe out our chat codebase completely and start the whole new app with payment as our main product. This product transformation also one of the key reasons that led us to this decision even though our current native app already using modular architectures, so it should be easy to remove only chat feature. But we think this is also the right moment if we want to migrate from native to hybrid (Flutter), considering Flutter will cut our development cost in half because of its natural benefit of cross platform tool and its ability to hot reload which will result in faster product development. The only downside is the requirement to learn a new programming language, Dart. But for us who have growth mindset as our culture it should not be a problem at all.

What makes switching from native to hybrid also feel easier is because we have Fortune on our side.

Fortune to the Rescue

For us migrating from native to hybrid was a bold decision. You can say that Fortune is one of the key factors that make us able to switch from native to Flutter smoothly. Fortune does not mean luck, but it is really fortunate to have Fortune. Fortune does not mean assets, but it is truly our great assets. Fortune is a design language system (DLS) which contains a collection of reusable functional elements (button, form, header, etc.) that are defined under certain standards. With Fortune as our guidelines, it help us to reuse as many UI components as possible in multiple screens and scenarios thus increasing our code efficiency and productivity. Combined with the agile process, we can do rapid prototyping.

You can read more how we architecting Fortune in this article.

Choosing the right Architecture?

Talking about design language system without design pattern is like scriptural study without understanding. Design pattern is one of a fundamental part of your application, so that you can maintain, scale, and test your project easily. Choosing the right architecture should be an obligatory step in the design and planning phase of software development. The lack of architecture in applications causes a major problem:

Code less readable
It will be more error prone
It will be difficult to maintain
Code is harder to test, which results in missing unit tests.
And many more

BLoC stands for Business Logic Components. It was created by Google and introduced at Google I/O 2018 and first presented during DartConf 2018, you can see the video on YouTube. It is created based on Streams and Reactive Programming. BLoC implements the observer pattern. Events are fed into stream that is the input into a logic block. The logic block figures out what response it needs to give and then sends that response back out as a state. BLoC uses advanced techniques like Streams and Reactive Programming. If you guys already familiar with RxSwift or RxJava, we think it wouldn’t be hard to understand what’s going on under the hood of BLoC. I will not describe briefly all BLoC components, if you want to dive deeper, this official documentation is the best place to go. Instead, we will give you our insight why we adopt BLoC architecture.

Why BLoC?

Most of native mobile engineers already know about MVVM. Yes, you can co-relate this architecture with MVVM. The only thing that will change is: BLoC will be replaced with ViewModel in MVVM. If you already know about MVVM, it is much easier to understand BLoC. Because BLoC is similar with MVVM, we can say that BLoC are

Easy to separate presentation from business logic
Easy to maintain code
Easy to test code
Easy to reuse code

That are what makes architecture is a good architecture, and BLoC has all of these capabilities. BLoC also defined as a state management system, so we know what state our application is in at any point in time. It helps us in managing state and make access to data from a central place in our project easier.

Technically with BLoC pattern we will got more boilerplate code. But It’s okay, we can create our own code generator to generate BLoC pattern codes.

Widgets send events to the BLoC via sinks
Widgets are notified by the BLoC via streams
The business logic which is implemented by BLoC is none of their concern

Thanks for the decoupling business logic from the UI, we can see a huge benefit from BLoC:

We may change the business logic at any time with a minimal impact on the application
We may change the UI without any impact on the Business Logic
It is much easier to test business logic

Since BLoC is heavily used and recommended by Google, they have really good examples, like this one:
https://github.com/filiph/state_experiments/tree/master/shared/lib/src/bloc_complex.

If you want to start creating apps with the BLoC architecture we would strongly recommend two libraries that make working with it much easier, bloc and flutter_bloc.

Migration Strategy

Before we started to code using Flutter, our research team responsible to init the project and create the skeleton code, which consist of network call, object mapper, storage, dependency injection, shared style object, etc. The research team are not only benchmarking between native and Flutter but also do some research which architecture we should use. Not only they provide the sample code, but also article and other references as guideline to make other engineers easier to onboard to Flutter.

For rewriting screen process. We started with creating UI kit components before creating each screens. This will ensure that each individual engineer is not blocked by a particular UI kit not being implemented yet. How do we determine which UI kits components must be created first? With the help of our design language system (Fortune), we can start by creating the most widely used UI kit components in our app, like text field, button, avatar, header, loading indicator, empty state, etc. After that widely used components are done we can start on creating each screen and we can create specific UI kit components on each screen along the way. Flutter also has this amazing hot reload feature that allows us to see the reflected change after building the user interfaces or even adding certain feature to our app without running our application afresh over and over again. Thus makes us able to validate our feature faster and as early as possible.

Final Thoughts

Whether you are developing an entirely new app for one or both iOS and Android, or simply adding a new feature to existing native apps, Flutter is the ideal platform for your project. In general, development speed is cut roughly in half using the Flutter cross-platform development tool, but feature delivery time is of course dependent on the specific task. Flutter also solves many common UI development issues, and its hot reload feature dramatically reduces development time.

Don’t forget that a well chosen architecture saves a lot of problems with maintenance and development. It is very important during developing and maintaining a project. There’s not right or wrong solution. In order to adopt an architecture, it is important to understand your necessities. For us and our needs, the BLoC pattern is our best choice. BLoC separates the view layer from business logic very well. This entails better reusability and testability. Even though it seems that to handle simple cases, you need to write more code. But it’s okay, this BLoC architecture will become more useful as the complexity of our application increases. It is important to always be curious, learn and think if that’s the right solution for you.

We hope that this article series can enlighten and inspire other companies that consider to change their mobile tech stack and also for individual engineers who want to explore hybrid mobile app frameworks.

This is the Part 2 in a series of articles about Flutter in Oy Indonesia.

If you are passionate about solving interesting and impactful challenges, OY! Indonesia would be a great playground for you to unleash your creativity. Join us!

Want to experience the most seamless payment experience? Try to download OY! in Google Play and App Store and please feel free to give us feedback about it 👌🏼.