What Is a Super App? Lessons from WeChat, Grab & Gojek

Table of Contents

• What Is a Super App, Exactly?
• How Mini App Architecture Actually Works
• WeChat: The Messaging App That Became an Operating System
• Grab and Gojek: Super Apps Built on High-Frequency Logistics
• Revolut and the Western Version of the Super App
• When Bundling Services Into One App Makes Sense
• The Modular Path: From One Service to a Platform
• Platform Rules: What Apple and Google Allow
• Risks: Security, Data Concentration and Maintenance Load
• Frequently Asked Questions

A super app is a single mobile application that gives users several independent services — messaging, payments, transport, food, shopping — usually through embedded modules called mini apps. The largest example, WeChat, reached 1.43 billion combined monthly active users as of March 2026.

The economics behind the model are blunt: getting someone to install a new app is expensive, and adding a service to an app they already open daily is comparatively cheap. That asymmetry is why Asia's biggest digital companies spent the last decade collapsing dozens of services behind one icon.

What that means for you depends entirely on your starting point. This guide explains what a super app is, how mini app architecture works at a technical level, what the three canonical examples actually prove, and how to decide whether bundling services into one app is right for your product. If you have not shipped a mobile product yet, start with the mobile app development process — this article covers the step after that, platformisation.

What Is a Super App, Exactly?

A conventional app does one job: banking, parcel tracking, food ordering. A super app does its core job and acts as a platform that hosts other services. The dividing line is commercial rather than technical: in a super app, some of the services are built by someone other than you.

The clearest definition sits in a securities filing. Grab, one of Southeast Asia's largest platforms, defines the term in its 2025 annual report as "an integrated mobile application of many applications that aims to provide a one-stop marketplace platform with multiple offerings delivered via a single technology platform and third-party integrations."

Gartner frames it similarly: a super app is a frontend platform offering core features plus access to independently built mini apps. Gartner's widely quoted forecast is that by 2027, more than half the global population will be daily active users of multiple super apps.

Here is how the two models compare in practice.

Market expectations are high. Research firm IMARC's super apps market analysis puts the market at USD 114.2 billion in 2025, forecast to reach USD 595.8 billion by 2034 at a 20.15% CAGR. The same analysis gives Asia-Pacific a 46.8% share in 2025 — the model is still strongest where it was born.

How Mini App Architecture Actually Works

The most common misconception is that a super app is just a big app with a lot of screens. Technically, something more specific happens: the main app becomes a host, and services run inside it as separate packages.

The W3C MiniApp white paper defines a super app as "a software platform that hosts and supports other applications (i.e., MiniApps), enabling their execution by using the platform's resources." A mini app, per the same document, ships as a compressed archive containing a configuration document in the root directory, an app-level logic file with lifecycle callbacks, page templates, CSS and JavaScript — with digital signatures supported for integrity validation.

Google's mini apps documentation covers the practical side. Mini apps are written in dialects of HTML, CSS and JavaScript, typically run 2-4 MB in size, execute in a WebView inside the super app rather than on the operating system, and are served as encrypted packaged archives from the super app provider rather than from the developer's own origin. Device APIs are reached through a JavaScript bridge. Discovery works differently too: mini apps are often found ad hoc through branded 2D barcodes, in-app search, or a link shared in a chat.

The easiest implementation to inspect today is Telegram. Per the Telegram Mini Apps documentation, you add a single telegram-web-app.js file and get a window.Telegram.WebApp object, through which the host exposes theme data, safe area insets, bottom buttons, the back button, accelerometer and gyroscope, geolocation and biometric authentication. The limits are explicit: 1,024 items per user in cloud storage, 5 MB in device storage, 10 items in secure storage, and 4,096 bytes of data sent from a mini app to its bot.

Three practical consequences follow:

• A mini app is a web app, but not a web page. It is packaged, signed, reviewed by the host and restricted to the APIs the host chooses to expose.
• You are only as capable as your host. If the host does not surface a device capability, your mini app cannot reach it.
• Your release cycle splits in two. The core binary goes through store review; mini apps update within host policy without waiting for it.

If store-independent distribution is what attracts you here, the trade-offs in PWA vs native app cover the other route to an app-like experience built on web technology.

WeChat: The Messaging App That Became an Operating System

WeChat started as messaging and never stopped absorbing services. According to Tencent's first quarter 2026 results announcement, combined monthly active users of Weixin and WeChat reached 1,432 million as of 31 March 2026, up from 1,402 million a year earlier.

The more instructive detail in that filing is where the money now comes from. Tencent attributes marketing services growth partly to mini game, mini drama and Mini Shop advertisers, and reports that Mini Shops sustained rapid year-on-year growth in gross merchandise value. In other words, the mini app layer has become an advertising and commerce channel in its own right — not a convenience feature bolted onto messaging.

Scale elsewhere in the mini app world is comparable. The W3C white paper cites more than one million mini programs and 230 million daily active users on Alipay's platform, and over 150,000 smart mini programs with 270 million monthly active users on Baidu's.

The lesson is uncomfortable for anyone planning a super app from scratch: WeChat did not win by launching many services. It won a daily habit first, then rented that habit out.

Grab and Gojek: Super Apps Built on High-Frequency Logistics

Grab began with ride-hailing and expanded into food and grocery delivery, payments and financial services. Its annual report puts monthly transacting users at 35.5 million in 2023, 41.3 million in 2024 and 47.2 million in 2025. Note the metric: not installs, but unique users who actually transacted in a given month.

Gojek started as a call centre dispatching motorcycle couriers. Per GoTo Group's fourth quarter and full year 2025 results, group core gross transaction value rose 49% to Rp400 trillion for the full year, annual transacting users grew 24% to 66 million, and the fintech arm reached 26.2 million monthly transacting users in the fourth quarter.

Two patterns repeat across both companies:

• The core service is high-frequency and logistics-heavy. Rides and deliveries generate multiple sessions a week, which is what makes a second and third service viable.
• Payments is the hinge. In both cases a wallet sits between services, turning separate transactions into one account relationship. That is the module that converts a bundle of apps into a platform.

If your core product is opened monthly rather than weekly, neither pattern transfers. Adding services to a low-frequency app produces a cluttered app, not a super app.

Revolut and the Western Version of the Super App

Western super apps rarely look like WeChat. They tend to be vertical: one domain, many products, one account. Revolut is the clearest current example, and its numbers are specific.

Revolut's 2025 annual report reports a retail customer base of 68.3 million (up 30%), 767,000 business customers, £4.5 billion of revenue and £1.7 billion of profit before tax at a 38% margin. The sentence that matters most for this discussion is this one: "Internally, we now track a total of 11 different product lines that exceeded £100 million revenue in 2025."

Eleven product lines inside one app, each at material scale, is the super app thesis working — without a third-party mini app store, and without leaving financial services. That is the realistic shape of the model in the US, UK and EU: depth inside one domain rather than breadth across unrelated ones.

The general-purpose version has struggled in these markets for reasons worth naming plainly. Users already have entrenched single-purpose apps and little reason to switch. Privacy expectations make broad cross-service data sharing harder to justify. And competition regulators watch platform consolidation closely — the UK Competition and Markets Authority's mobile ecosystems market study examined exactly this kind of gatekeeping power in mobile, concluding that self-contained ecosystems make it difficult for other firms to compete meaningfully.

So the Western playbook is narrower: pick one domain where you own the customer relationship, then go deep.

When Bundling Services Into One App Makes Sense

The decision reduces to three questions. Is it the same user? Is the frequency high enough? Do the services feed each other? The matrix below makes those concrete.

The constraint that decides most of these cases is not budget — it is product management load. Four services in one app means four backlogs sharing one release train. If one module slipping blocks the other three from shipping, you do not have a super app; you have a large monolith.

The second trap is confusing menu space with usage. Every module wants a slot on the home screen, a step in onboarding and a permission prompt. If stacking four services lowers conversion on your core flow, the net gain is unclear. That is why every module needs its own measurement from day one, which makes the event-based setup in mobile app analytics metrics a prerequisite rather than a nice-to-have.

The Modular Path: From One Service to a Platform

Nobody writes a super app on day one. The sequence runs: one service to product-market fit, then modular architecture, then opening to third parties.

Stage 1 — One service, sharp core. The goal is to do one job well enough that people open the app more than once a day. Deliberately narrowing scope here is what the minimum viable product approach is for.

Stage 2 — Internal modularity. Split the codebase along feature domains so each module owns its screens, its state and its API contract. The test is whether you can change one module without touching the others. On the web, Module Federation is the mature tool for this; mobile stacks use comparable runtime module loading.

Stage 3 — Shared platform layer. Authentication, payments, notifications, permissions and analytics consolidate into one core that modules consume. Get this wrong and every new service arrives with its own login screen and its own checkout — the single most irritating outcome for users.

Stage 4 — Opening to third parties. A mini app platform means an SDK, a review process, revenue sharing and developer support. Only teams with proven demand should attempt it, and the groundwork is almost always an API strategy first; API integration covers how those contracts get defined.

On cost, a modular build is not dramatically more expensive than a single-service app at stage one. The difference shows up in the marginal cost of each new module. For a rough band against your own scope, the app cost calculator gives a starting range, and app monetization models covers how to structure revenue per module.

Platform Rules: What Apple and Google Allow

The most frequently skipped item in super app plans is store policy. Apple addresses it directly in section 4.7 of the App Review Guidelines: apps may offer HTML5 and JavaScript mini apps and mini games that are not embedded in the binary, but you are responsible for all such software, and software that breaks one guideline leads to rejection of your whole app. The sub-rules require:

• Mini apps must follow privacy guidelines, include a method for filtering objectionable material, a content reporting mechanism and the ability to block abusive users (4.7.1).
• Digital goods and services must follow guideline 3.1, meaning in-app purchase (4.7.1).
• You may not extend or expose native platform APIs to the software without prior permission from Apple (4.7.2).
• Sharing data or privacy permissions with any individual mini app requires explicit user consent in each instance (4.7.3).
• You must provide an index of software and metadata available in your app, including universal links to all of it (4.7.4).
• You must let users identify software that exceeds the app's age rating and apply an age restriction mechanism (4.7.5).

On Android, the binding constraint concerns runtime code loading. Google Play policy prohibits apps from downloading executable code such as dex, JAR or .so files from a source other than Google Play, but that restriction does not cover code running in a virtual machine with limited access to Android APIs — JavaScript in a WebView, for instance. That exemption is a large part of why mini app frameworks are built on web technology.

The practical takeaway: running a mini app platform is as much a compliance function as an engineering one. Indexing, content moderation, age gating, per-instance consent and payment routing all have to be in the product plan from the start. The common grounds for rejection are listed in app store rejection reasons.

Risks: Security, Data Concentration and Maintenance Load

A super app consolidates your attack surface along with your services. The systematic review SoK: Decoding the Super App Enigma by Yuqing Yang, Chao Wang, Yue Zhang and Zhiqiang Lin treats super apps as "operating systems" and catalogues 13 security mechanisms and 10 security threats across these platforms. Its root cause analysis finds that security assumptions get violated in three places: issues in the underlying systems, the implementation of isolation, and vetting.

Translated into product terms:

• Isolation can exist on paper only. You have to test that mini apps cannot reach each other's data or the host's privileged APIs. Assuming it is not enough.
• Data concentration amplifies any breach. When payment, location and contact data live under one roof, a single flaw exposes all of it at once. Under GDPR and CCPA, data minimisation and purpose limitation get harder in this architecture, not easier — the consent logic described in cookie and consent compliance has to be rebuilt module by module on mobile.
• Vetting is a process, not a launch task. Accepting third-party modules means standing up continuous review and enforcement.
• Maintenance compounds. Each module brings its own dependencies, SDK upgrades and breakage points, so annual maintenance needs to be budgeted differently from a single-service app.

Teams planning this architecture should close the basics first; the checklist in mobile app security best practices covers what needs to be in place before modules multiply.

Frequently Asked Questions

What is the difference between a super app and a regular app?

A regular app does one job and one team builds all of it. A super app runs a core service while also hosting other services as mini apps, some of them built by third parties and shipped independently of the core release.

What is a mini app?

A mini app is a small web application that runs inside a super app. It is written in dialects of HTML, CSS and JavaScript, typically weighs 2-4 MB, and executes in the host's WebView rather than on the operating system. Access to device features is limited to the JavaScript bridge the host exposes.

What are the main super app examples?

WeChat in China, built on messaging with over 1.43 billion combined monthly active users; Grab in Southeast Asia, built on ride-hailing with 47.2 million monthly transacting users in 2025; Gojek within GoTo Group in Indonesia, built on courier delivery with 66 million annual transacting users. Revolut is the clearest Western example, with 11 product lines each exceeding £100 million in revenue in 2025.

Why are there no WeChat-style super apps in the US or Europe?

Users already rely on entrenched single-purpose apps, privacy expectations make broad cross-service data sharing harder to justify, and competition regulators scrutinise platform consolidation in mobile closely. Western super apps therefore tend to go deep inside one domain, such as financial services, rather than broad across unrelated ones.

Should a small or mid-sized company build a super app?

Building a general-purpose super app is not realistic at that scale. What does work is a narrow multi-service app for your existing customer base — three or four modules that feed each other, such as ordering, delivery tracking, support and loyalty. The qualifying test is whether your app is opened at least once a day.

Do Apple and Google allow mini apps?

Yes, conditionally. Apple's App Review Guidelines 4.7 permits HTML5 and JavaScript mini apps while requiring an index with universal links, content moderation, age gating, per-instance permission consent and in-app purchase for digital goods. Google Play prohibits downloading executable code from outside Play, though JavaScript running in a WebView falls outside that restriction.

What is the biggest risk of a super app?

Data and security concentration. When payment, location and communication data sit in one application, a single vulnerability affects all of it. Academic work on the model points to module isolation as implemented, and third-party vetting, as the two most fragile points.

A super app is not an architectural goal — it is the downstream result of a high-frequency core service. Build one service people open daily, split the codebase into modules, consolidate identity and payments into a shared layer. Only once those three hold does hosting other services become worth discussing.

If you are weighing a move from a single-service app to a modular product, or scoping a multi-service build from scratch, we can work through the architecture with you. Talk to us about mobile app development and the trade-offs in your case — get in touch.