Adding Flutter to the development of RappiBank - Introduction

Published in

RappiBank

8 min readFeb 14, 2022

Original article (spanish) published in RappiTech Blog.

This is the first in a series of three articles — which we will be publishing in the coming weeks — based on an internal research project to study the possibility of including multiplatform development to build our mobile applications.

Motivation

RappiBank’s Mobile development teams are currently segmented by Android and iOS teams who perform broadly similar requirements using native development technologies for both platforms.

For many years, the industry has developed multiple technologies to create mobile applications that can be executed on the most used platforms in the market through a single code. However, a major recurring problem was not achieving a user experience similar to the native one. After many different approaches and years of experimentation, happily today, we already have technology with this capability.

But, how can we benefit from this if we already have a complete development done in native technologies?

The answer is… by integrating them!

If we can develop multiplatform components and integrate them into current native developments, we would get substantial advantages such as:

Development times / Capacity: Instead of having two teams doing the same thing for the two platforms, we would unify efforts in a single one that can develop for both, accelerating the capacity and development times.
Quality times: We can reduce QA times by testing only one base application to detect errors during development, leaving only the integration testing in the specific platforms in an advanced stage of the cycle.
Unified design: Using the right technology, we can have an identical user interface on both platforms, even on legacy devices that do not have the latest operating system updates and, therefore, the latest native visual components.
Fewer errors: By having a single code, the possibility of development errors decreases.

Flutter

We must have the right technology and implementation strategy for such an ambitious goal.

The chosen technology is Flutter, an open-source framework developed by Google for building multiplatform applications from a single codebase. We decided it for having the following features:

Similar performance to native applications.
Features that make its development faster than we know in native technologies.
Own components (not OEM) that simulate the behavior of native ones, allowing us to have a unified design.
A declarative and flexible UI development technique.
The potential of the technology: Currently, we can build apps for mobile, web, desktop, and embedded devices.

Alternatives

There are other technologies in the market for multiplatform mobile development. However, none of them have the same features or share a similar approach to the architecture proposed by Flutter. We will list comparisons only with those with a similar performance to native applications, leaving out those such as the combination Cordova / Ionic whose performance by a logic of how they were conceived (being essentially Web applications) can never achieve that goal.

React Native

Xamarin

Beyond all the aspects analyzed in the comparisons above, the main advantages of Flutter (and why we choose it) can be summarized in two milestones:

Its architecture gives us total independence of the UI objects since it works with its own components that simulate Android / iOS views. You can think of it as a video game framework where you literally raise an engine -Skia- who renders the objects on the screen. This gives us a substantial advantage in the unified design and excellent performance, as it does not need to bridge our technology and the OEM components to render views.
All the Flutter code is compiled as machine code and executed natively (AOT, for ARM/x64 CPU architectures). Having to communicate only with platforms to exchange information that we are handling in the platform layer (Android / iOS), use their services to access the camera, file system, etc., or require data from a specific sensor.

Kotlin Multiplatform

This technology, although still in Alpha phase, is exciting. It seems an evolution to the concept that brought projects like J2ObjC (transpiling to ObjectiveC) or Multi-OS Engine and RoboVM (generating native ARM/x86 libraries like Kotlin Multiplatform) to compile Java on iOS and share the same business logic with Android.

Kotlin Multiplatform does not come to compete directly with Flutter. Their goal is to solve the business logic in a common code and compile it to machine code libraries. Later, the native developments of each platform make use of these libraries and their logic. While Flutter offers a complete solution for mobile development, that is, to create business logic and everything related to an application cycle and its views. In short, to make a complete application with the same source code.

The exciting thing about the different approaches is that both technologies complement what we intend to do in this work. One problem we have when including Flutter in a joint implementation to native development is solving the common logic between platforms. For example, if we must use the same network logic, we will still have to maintain the business logic in Android, iOS, and Flutter, if we want it to have total independence. It does not make sense to raise a Flutter Engine that has the logic to consume them from the platforms. However, with Kotlin Multiplatform, we can solve this issue in a single layer. This way, Android, iOS, and Flutter developments can use this unified logic. To better understand this approach, we recommend reading the first exposed article, Flutter + Kotlin Multiplatform, Write Once Run Anywhere.

Experiences from other companies

Flutter was initially conceived for the creation of complete applications. Each platform’s implementations consist of launching a native application with an Embedder layer with a default configuration that initializes all the layers required by Flutter and then launching a native fullscreen view containing only the embedded Flutter instance. From then on, everything we see and interact with is pure Flutter.

Not long after the public launch of the technology, the idea of performing partial implementations -so as not to require rewriting an entire application- began to emerge from some players interested in adopting it but who already had productive native apps. So, before there was an official solution, there were several approaches and private implementations to achieve this integration. We need to analyze the treatments these companies adopt, as they have precious information to understand the Flutter architecture and the common issues we need to solve.

Many of these articles are in Mandarin Chinese. Several of the players that innovated with this technique are large Chinese companies. In those cases, we will add the original article and a link to the translation provided by Google, which, by the way, is amazingly accurate.

ByteDance

Toutiao or Jinri Toutiao is one of China’s most important news and content platforms. The company is also known for being the creator of the TikTok app.

Let Flutter truly support View-level hybrid development

Alibaba

The Chinese e-commerce giant. At present, Ali’s Xianyu development team uses Flutter in large-scale projects. They have also created and released their implementation library called flutter_boost.

Flutter new expert road: hybrid development

Flutter hybrid stack reuse principle

Alibaba: start hybrid development with flutter_boost

Nubank

Nubank is one of the most important fintech on the continent. It is currently developing all its new features with Flutter, and they plan to migrate the existing native ones. Before officially adopting the technology, they made a complete analysis where they studied and compared React Native (technology with which they already had experience for having made another application of the company called NuConta), Kotlin Multiplatform, and Flutter.

Article, analysis, and comparisons with other technologies and video of Flutter Dev Stories

Weidian

Weidian is the largest store-building platform for WeChat, the top messaging app in China.

Practice of Flutter Hybrid Stack Management Technology in WeChat Store

Mafengwo

Mafengwo is one of China’s most used travel sites, where you can post information about places, trips, and user reviews. It has a mobile application called Mafengwo Travel App.

Flutter implementation principle and cross-platform development practice in Mafengwo

Upcoming articles

In the second article, we will focus on our proposed Android/iOS — Flutter integration, analyzing topics such as:

Integration method.
Ways of communication between the platforms and Flutter: Information exchange; routing/navigation.
Partial views and multiple Flutter instances.
Shared resources management: Icons, fonts, and images.
Performance analysis, memory management, and application weight.
Technical limitations.

And we will end a few weeks later with a third and last article where we will discuss topics such as:

Flutter development bases and recommended bibliography.
Libraries and tooling.
A suggestion of development architecture in Flutter.
FAQs.
Conclusions.

We assure you that you won’t get bored.

Stay tuned!