Super App Architecture Series — Part 4: Architectural Considerations for Building a Scalable and Secure Super App

Super apps have become a prominent architectural pattern for organizations seeking to unify heterogeneous services under a single access point. Yet, behind the polished user experience lies a non-trivial set of design trade-offs, especially when enabling a multi-vendor Mini App ecosystem.

In previous articles, the discussion has focused on foundational aspects of building a Super App, including clarifying what a Super App essentially is, distinguishing between systems that truly satisfy this definition and those that do not, as well as examining the core issues that need to be addressed during the development phase, particularly with respect to security and high‑level system architecture.

In this article, the emphasis will be placed on the topic of optimization, a dimension that is often underrepresented or entirely omitted in public discussions. The perspectives presented here are largely practice‑oriented and are rarely shared openly; in fact, developers and software architects may be reluctant to bring them up, especially when the audience includes project owners or business stakeholders.

The reason is that system optimization is a relatively complex domain, and it typically receives serious attention only when concrete problems begin to surface — an outcome that, in practice, is almost inevitable over the lifetime of any sufficiently large system. At that point, however, the cost of optimization tends to be substantial.

Note: All of the content discussed below is formulated under the assumption that the development environment is based on React Native. Nonetheless, the principles and methodological approaches presented can be applied, with appropriate adaptations, to other runtime engines and platform ecosystems.

1. Splitting Bundle Mini Apps

Why is this important?

Splitting bundles in Mini Apps plays a critical role in optimizing both system performance and user experience. As a Mini App grows in size, it tends to consume more system resources — especially RAM — and loading the entire application at once can significantly increase startup time.

The splitting‑bundle approach allows the system to load into memory only the components that are actually required at a given point in time, instead of loading a large application package (for example, 20–30 MB) containing many modules that are not immediately needed. This approach reduces resource consumption, improves response time, and provides a smoother experience for the user. At the same time, decomposing the application into independent bundles enables selective loading and deployment of each part, thereby improving the overall system’s scalability and maintainability.

Choosing an appropriate splitting strategy for Mini App bundles depends on multiple factors, including application size, user base characteristics, and the specific functional requirements of each Mini App. A commonly adopted strategy is to decompose the application into independent bundles, where each bundle encapsulates a clearly defined set of components and features that can be downloaded and deployed separately. This organization allows users to download and use only the required functionality instead of loading the entire application from the outset, thereby shortening load times and optimizing resource utilization.

The splitting‑bundle strategy is also closely tied to, and directly impacts, the architecture of the MiniApp SDK and the native plugins, which together govern and maintain the interaction between Mini Apps and the Main App. In systems that must manage a large number of Mini Apps originating from multiple vendors, standardizing the splitting mechanism, the chunk‑loading workflow, and the verification process for both Mini Apps and their chunks becomes especially important. Any change at the Core layer of the system propagates to the MiniApp SDK, native plugins, and the broader vendor ecosystem, increasing the risk of service disruption and negatively affecting the end‑user experience.

Implementing a splitting‑bundle strategy is by no means trivial, as it requires coordination and alignment among multiple stakeholders, from development teams and service providers to end users. Nevertheless, if the goal is to achieve optimal performance and user experience, adopting such a mechanism becomes an almost inevitable long‑term architectural choice.

Consequently, rather than postponing and only introducing it when the system has already become unwieldy, designing and implementing splitting bundles from the early stages will help reduce future adjustment costs and mitigate technical risks during system evolution.

(Details related to the concrete implementation process — including technology choices, specific techniques, and common pitfalls and risks during deployment — will be addressed in a subsequent article.)

1.2. Splitting Bundle & anti-tampering

During the implementation of the splitting‑bundle mechanism, I made a number of adjustments were introduced to enhance anti‑tampering capabilities, particularly in scenarios where the system allows multiple teams and numerous Mini Apps to coexist within a shared ecosystem. A more detailed discussion of these considerations can be found in the following reference.

[embed]Support bundle verification with multiple public keys · Issue #826 · callstack/repack Description The situation we're facing is as follows: We have multiple independent MiniApp development teams, and we…github.com

Inject bundle

When an attacker deliberately injects malicious bundles into a device through channels such as adb commands (for example, by directly overwriting bundle or chunk files inside the application directory), ensuring the integrity of each bundle — and even of individual chunks — becomes significantly more complex.

In such a context, relying solely on verification of remotely delivered bundles, without a consistent protection, binding, and validation strategy for locally stored files, leaves the system vulnerable to code injection or content replacement that may go undetected until it causes damage.

Therefore, anti‑tampering considerations must be treated as a first‑class concern when designing the splitting‑bundle mechanism, both at the level of entire bundles and at the level of individual chunks, to prevent the inherent flexibility of Splitting Bundle from turning into an additional attack surface for adversar

2. Mechanism for upgrading MiniApps from the Main App

First, let us consider the simplest model for downloading a Mini App.

Seamless Update

This mechanism, commonly referred to as Seamless Update, is widely adopted as a standard and relatively safe approach for upgrading firmware or applications on mobile devices, with the primary goal of minimizing disruption to users during the update process.

Conceptually, the mechanism operates in a straightforward manner: each Mini App is associated with two storage partitions, where one partition holds the currently active version while the other serves as a standby partition for storing the new Mini App version.

Once the new Mini App package has been fully downloaded and installed onto the standby partition, the system switches the active state to this partition, thereby replacing the previously running version.

This approach enables updates to be applied safely, limits the impact on the Mini App’s ongoing operations, and allows for near‑instant rollback if any errors occur during the download or deployment of the new version.

2.1 Authentication Mechanism for MiniApp Packages When Downloading Main Apps

In a system architecture where Mini Apps are developed by multiple independent vendor teams, a mandatory authentication workflow must be enforced before any Mini App can join the ecosystem and be distributed, downloaded, or installed on the Main App platform.

This authentication pipeline typically comprises the following verification stages:

• Signature Verification: Implements digital signature mechanisms to ensure that Mini Apps are distributed from trusted sources and remain unmodified after the signing process.
• Integrity Verification: Validates Mini App identification attributes including package name, version number, unique identifier, and metadata to confirm legitimacy and detect potential tampering or spoofing attempts.
• Safety Verification: Conducts security assessments to ensure Mini Apps are free from malicious code, harmful scripts, malicious content, or behaviors that could pose risks to device integrity and user data privacy.

This authentication framework ensures that all downloaded and installed Mini Apps meet minimum security requirements and do not disrupt normal system operations.

The specific implementation methods, processing workflows, and underlying technologies for this authentication pipeline will be detailed in a separate technical article.

In multi-vendor environments, each development team is provisioned with a unique signing key to digitally sign their Mini App packages prior to distribution. This approach enables clear source traceability and establishes accountability boundaries for each participating vendor

Therefore, we need a mechanism for distributing Public Keys.

3. Roll-Out Mini Apps — Portal Roll-Out

This category represents one of the most effort‑intensive aspects when aiming to design and implement the system in a methodical, consistent, and efficient manner. Before delving into technical details, it is essential to define the overall problem statement and the intended operational scope of the system, as these initial assumptions directly influence the complexity of the system architecture.

A set of guiding questions below helps determine the effective “size” and scope of the problem domain:

• Does the Super App integrate Mini Apps from external vendors, and how are these applications classified — as Partner Apps or In‑house Apps?
• Will the system operate its own Mini App Store, and are vendors allowed to upload and update their Mini Apps directly on the platform?
• How many Mini App categories does the platform support — a single Mini App type, or multiple variants such as WebApp‑based Mini Apps, ReactJS‑based Mini Apps, etc.?
• What level of security assurance is required — are there strict business‑level security mandates, and what are the minimum compliance standards that must be met?

At a conceptual level, the following diagram provides an overview:

On the left side, the simplest form of deployment for a Mini App is illustrated: the user downloads a single compressed package containing the complete bundle, resources, and all related components, which is then extracted and activated within the Main App. However, this approach typically increases load time and forces the user to download redundant contents that may not be required during actual usage.

In many scenarios, only a small portion — often a few final chunks — of the Mini App changes between releases. Ideally, users would only need to download a few hundred kilobytes of incremental data. In practice, however, they often need to download the entire archive, including unchanged resources.

To optimize both performance and user experience, a more effective approach is “progressive loading on demand” — downloading only the required code bundles and resources, caching them locally, and reusing cached data until a newer version of the Mini App is available.

This architecture defines what may be referred to as an Online Mini App — a native application that effectively operates with the behavior of a web browser.

Achieving this design requires intentional architectural planning from the early adoption of bundle splitting strategies, rather than applying patchwork modifications afterward.

Without standardization at the outset, later adjustments will demand substantial redevelopment effort — including restructuring of the Mini App itself, the MiniApp SDK, the Main App, and other supporting systems such as the Portal Rollout environment, distribution and storage infrastructure, and public‑key management services.

If you find this exploration of Super App architecture useful or thought‑provoking, feel free to share your own perspectives or questions in the comments — any critical feedback, alternative designs, or real‑world war stories are very welcome.

Your engagement, whether through a comment, a clap, or a follow, is a strong signal for me to continue deep‑diving into topics at this level of technical detail.