Super Apps development model explained !
Introduction
If you ever stumbled, lately, on a tech article talking about Super Apps, it would probably mention that they were first invented in 1999, by Mike Lazaridis, the founder of Research in Motion (RIM), the manufacturer of the BlackBerry device.
Mike has defined Super Apps as applications which make use of all the BlackBerry resources available. From usage of notification pop ups, context menu integration right down to being able to access any application from within anywhere on the device. Deep integration across the whole device.
However that is one definition of what a Super App actually is. Companies in Asia lately shifted and used the concept of blackberry super apps to respond more to mobile app development modern issues :
Decreased App retention Rate & Customers Loyalty
Statistics show that companies usually have a hard time keeping users engaged with their mobile services. To improve retention rate, companies changed their strategies to offer various services to keep the user hooked to their apps. They target more customers and create more meaningful engagement and user experience, using a more captive and appealing ecosystem.
Reinforcing partnerships
Some companies may even offer services that do not belong to their core services. For example, one of the most famous super apps in Asia is called Grab. When Grab was first launched, it was a ride-hailing app like Uber, offering only taxi booking and related services.
Few years later, they expanded their business to cover various domains like food delivery, ride-sharing and even banking and financials, all on the same application.
Bringing together all these domains outside of their bounds of expertise requires partnering up with other companies, and integrating third party partners, to build a healthy ecosystem of services.
Grab chose to partner up with OVO as a payment service provider for its super app.
Targeting Users needs
Targeting various services gives companies a complete understanding of their users behaviors and preferences. This helps to increase personalizing services per user or a group of users, and gives enough data and insights to promote certain services.
The fact that services are accessible from one application gives a seamless, easy, and compelling user experience.
Use cases Study : THE right solution does not exist
After studying the most famous super apps on the market today, we noticed that there are various ways to create a Super App.
One of the biggest super apps in the world is WeChat, created in China, by the company Tencent.
WeChat started as a messaging app, and then gradually added more services, called mini-apps. Today, they have more than 1 Billion users per month, and over one million mini apps including payment, games, e-commerce, etc. The app is distributed on both Android and iOS platforms, using the official Google play and Apple stores.
When WeChat is downloaded, it is installed as a single application on the phone. This app works as a platform or a host for the services mentioned above.
The host is developed in native Android and iOS technologies, and is responsible for launching and controlling the mini-apps. Mini-apps, developed using web technologies (HTML, Javascript), are completely independent from each other. Each mini-app runs a small, lightweight service.
Tencent does not develop and maintain all the services on the app. Instead, they offer tools (IDE, SDK, UI components, etc) for other companies and developers to develop, test and maintain their mini-apps, according to WeChat’s development and user experience guidelines.
This allows WeChat partners and non-partners to be autonomous creating and adding their services to the app.
Using Web technologies to create mini-apps gives more freedom and flexibility than native ones; one of Web applications characteristics is the possibility to update without installation. WeChat used this to bypass updating mini-apps through the stores (Google Play, Apple Store). Instead, they use over the air updates where the mini-app downloads and installs its update bundle, instantly, and without rebuilding the whole super app.
Revolut
Revolut, one of the most famous digital banking apps today, took another approach in developing their super app.
The app offers features mostly related to banking and financials like crypto trading, travel insurance, payments, budgeting, virtual cards, etc. It is also distributed on both platforms Android and iOS, through both stores.
The company has two teams, one for each mobile platform. Each team has approximately 60 developers, using native technologies (Swift, Kotlin). Each platform has cross functional teams that are organized by feature (payment, trading, lifestyle, etc).
All these teams work on a single source code repository per platform, and use clean architecture and MVVM pattern to easily maintain and scale up their app over time.
In iOS, they used iOS frameworks to encapsulate, modularize and reuse features across the app. This allows teams to, separately and independently, develop and test different features.
Revolut does not have a lot of partners compared to WeChat. Most of Revolut’s partners’ services were accessible simply through a URL that redirects to the partner’s website. The effort to integrate partners is small compared to WeChat.
How to develop a Super App ? Possible scenarios using mobile native technologies
1- Challenges
To add as many services, the app will require a large storage space on the mobile device. This is a challenge since sometimes Android and iOS stores can refuse to distribute the app.
Users can also refuse to download and install the app, because of its large size, or when they have no interest in certain services. It is complicated to find the balance between giving users the most friendly and personalized experience, and offering a wide range of services.
Developing and maintaining these services will be complex. This will require a solid team organization, and a scalable, flexible technical architecture.
Another challenge is that integrating partners will require an open ecosystem, to be able to share the same technical and business guidelines, and work together easily.
As a result, developing a super app is not only a matter of which technical solution to choose. It is equally important to also think about what type of team organization to choose ? What kind of partnership would suit the company best ?
These questions have a direct impact on which technical solution to use to develop super apps.
Let’s take the example of a company that develops a super app integrating their own features, and others offered by partners. The company chooses to allow for their partners to access their source code, and for their teams to develop together.
Lots of questions need to be answered, and areas to be covered, before starting the development process, e.g., What repository strategy will they have to adopt ? Mono-repos ? multi-repos ? What team organization to match this strategy ? How will they work on the app simultaneously without blocking the development process ?
2- Technical solutions to respond to the challenges
2-1 iOS Platform
- Architecture : Modular and Scalable
Modular architecture is not a stranger to mobile apps development. It is especially adopted In large scale companies, where applications are constantly evolving and changing over time.
In our case, it is useful to subdivide the application to modules, each module represents a service or a feature. This keeps the modules functionally independent, while undergoing changes, and helps avoid conflicts between teams developing and maintaining them.
Modularity also promotes reusing common features, in order to meet different purposes without adding substantial code.
in IOS, Apple offers a solution to modularize the app, using Frameworks. A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. Multiple applications can use all of these resources simultaneously.
Each module will be represented by a framework. For example, an in-house payment framework that exposes payment related services.
You might get the question on how to actually know the boundaries and the functionalities for each module. A Lot of methods are proven very useful like DDD.
This decoupling gives developers the freedom to choose which architecture pattern to use for each framework, depending on its complexity or the development guidelines they set : MVVM, MVP, VIPER, etc
However, we recommend using the same architecture pattern for all frameworks, to be able to standardize the development guidelines across teams, to facilitate maintenance, and also to speed up onboarding new developers on the app.
- Partner Integration
Frameworks do not depend on the application core itself. That means you can develop, build, and package frameworks independently from the rest of the application.
This can allow partners to be less dependent on the main company to develop their services, then integrate it to the main application.
- Personalization
Using iOS frameworks does not give us too much freedom to personalize the user’s experience on the super app. Adding numerous services will increase the application size, since they will all be present on the device at installation time.
When the application is built, and ready to be uploaded on the store, all frameworks are packaged together in the same bundle. To remove or to add a framework, re-building the whole application is mandatory. However, it is technically possible to give users the chance to choose and manage which services they would like to see, by showing or hiding it in the app.
This will not completely remove the service from the user’s device, but will only rearrange the app so the user does not see it.
2-2 Android platform
- Architecture : Modular and Scalable
- Librairies
The Android platform offers a similar solution to iOS frameworks : Libraries. Libraries offer the same advantages as frameworks. If you like to know more about developing and using Android libraries, refer to this documentation(lien doc android).
However, it is not the only solution Android platform provides. Lately, Google uses another way to modularize the app called Dynamic features or on-demand modules. 
- Android Dynamic Features
Unlike the traditional Android approach, consisting of encapsulating the whole app source code into a single package, using On-Demand modules requires splitting the app to several modules or features, and packaging them separately.
Through the Dynamic Delivery mechanism offered by Google play store, your users can then download and install your app's dynamic features on-demand.
Keep in mind though, that, unlike libraries, dynamic features are strongly dependent on the core application.
- Partner Integration
The coupling between dynamic features and the core application makes it nearly impossible for teams to work separately. This does not allow partners to develop their features independently from the main company.
However, there are few options like, developing partner services, in-house, by the main company, or giving access rights to partners to work in the same technical environment.
- Personalization
The most important advantage of Android Dynamic features is personalization.
Since the features are packaged separately, they allow users to control the content they want to see on their app, and to personalize their own experience. They can download, install, or completely remove unwanted features, freeing up space on the device.
However, keep in mind that Google recommends using no more than 10 dynamic features in one application, because of performance limitations.
Conclusion
In this article, I have shared with you the challenges you can probably face, when developing Super Apps, and few solutions that can help you implement one.
The last thing I would add is that the list of solutions is not exhaustive; We saw the example of WeChat that leverages web technologies to develop Super Apps, and reaching more than 1 million services in one application.
Keep in mind that the right technical solution will always depend on your business priorities, your team's organization, and your partnership strategy.