Scaling Super Apps: Modular Architecture with FlutterFlow Libraries

Building super apps is becoming very common in large economies like the USA, India, and South East Asia, where users expect a single app to handle everything from food delivery and hotel bookings to payments and shopping. These are called super apps.

For example, Uber started with ride-hailing and now also offers food delivery (Uber Eats), groceries, package delivery, and even public transit, all in one app. Grab, from Southeast Asia, combines ride-hailing, food delivery, payments, and hotel bookings. Paytm, from India, includes mobile payments, recharges, bill payments, shopping, insurance, and ticketing.

Most of these super apps follow a hub-and-spokes model, where the main app acts as the hub, and each feature — like food delivery, groceries, or travel — is a spoke connected to it. This allows teams to build each service independently while keeping the overall experience integrated and seamless for users.

As super apps grow in complexity, so does the need for a modular architecture. In FlutterFlow, Libraries make this modularity possible.

Hub & Spokes model

The Hub & Spoke model separates an application into a central core (Hub) and modular, plug-and-play feature units (Spokes).

Hub (Core App) - Hosts the global UI shell (navigation, auth, layout) and manages shared state and routes.

Spoke Modules - Independently developed feature libraries (e.g. FlowEats, FlowMart, FlowStays) that represent complete user journeys. Each is imported into the Hub and integrated into the main app flow.

💡

This architecture also includes shared logic and UI modules, such as a Payment Library used across Spokes, and a Component Library used by both the Hub and Spokes for consistency.

Using Libraries to Modularise Features

Libraries are the recommended approach for building enterprise-scale applications or super apps with multiple features. They enable teams to develop features independently and reuse them across projects.

Since the launch of Libraries, you’ve been able to expose and access resources like custom code, app state, action blocks, and components in the consuming project.

With the introduction of Pages in Libraries (June release), the feature set became complete, allowing full feature modules to be built and packaged independently. Libraries can now encapsulate entire user journeys, making modular development seamless and scalable.

Super App Architecture Overview

In this super app example, we'll work with an eCommerce app that acts as the Hub, similar to the one used throughout the FlutterFlow documentation examples. This app imports feature modules structured as Libraries, organized by levels based on dependencies:

• Level 0: Hub (Main App)
• Level 1: Feature Libraries (Spokes) or independently developed modules representing major features like,
  • 🍔 FlowEatsLibrary (e.g., food delivery)
  • 🏨 FlowStaysLibrary (e.g., hotel bookings)
  • 🛒 FlowMartLibrary (e.g., grocery shopping)
• Level 2: Supporting libraries imported by Level 1 feature libraries such as PaymentLibrary (shared payment flows used by Eats, Stays, Mart)

💡

This structure enables each spoke to remain lightweight and focused, while still sharing common utilities through Level 2 libraries.

Navigation Across Libraries

When your main app (Hub) imports Library modules:

You can navigate to Level 1 Library pages directly e.g., open RestaurantHomePage from FlowEatsLibrary.

This provides a smooth development experience:

• All pages from all imported libraries appear in the Page Selector.
• You can define navigation flows that cross levels, such as:
  • MainHomePage → RestaurantDetailsPage (L1) → PaymentPage (L2)

✅

Navigation stack is preserved even across libraries, maintaining a native-feeling back navigation experience.

💡

To navigate to a library page or enable pages from a library to be navigated from the bottom navigation bar, refer to the Library Pages section in the documentation for detailed guidance.

Passing down data to a Library Page

When you add a parameter to a Library Page, you can pass data from the parent (e.g., Hub) to the child page (in a Library) just like you would for any other page, using the navigation action and setting the parameter values in the "Parameters" section of the action:

⚠️

If you add a required parameter to a page that you intend to include in the bottom navigation bar as well, make sure to also provide a default value for it.Otherwise, the page cannot be added to the bottom navigation bar from the Hub project and will trigger an error like:

State Management Between Hub & Spokes

As your super app grows into a modular system of interconnected libraries, managing shared state and data flow between modules becomes critical.

In a modular super app architecture, feature modules (Spokes) often need access to shared data such as user context, cart contents, or app-wide settings. This is where state management in FlutterFlow comes into play.

FlutterFlow provides two key mechanisms for enabling this: App State and Library Values. Together, these allow both the Hub and Libraries to manage and share data without tight coupling, preserving modularity.

1. App State:

App State variables can be defined inside any FlutterFlow project whether it's the main app or a Library and they are always scoped to the project that defines them.

When a Library is imported into a consuming project (such as a Hub app or another Library), the App State variables defined in the dependency Library become accessible and editable from the consumer. These are typically namespaced (e.g., FlowEatsLibrary.cartItems) to avoid conflicts.

Here’s a quick example: the address create/edit screens live in the Hub project, but whenever the user updates their address, it needs to be set in the Spoke libraries like FlowEatsLibrary so they always reflect the current delivery location.

However, the reverse is not true:

App State variables defined by the consumer project are not accessible to the dependency Library that it imports.

This one-directional access avoids cyclic dependencies, which are not supported and would break the modular architecture FlutterFlow enforces.

2. Library Values:

Library Values in FlutterFlow are a way for a Library to receive input from the parent project whether that's a main app or another Library.

They are defined inside a Library and can be accessed anywhere within that Library project. They can be either read-only inputs like userId or themeColor, or actions that act as callbacks provided by the parent project, such as onComplete or onBackPressed.

If you need to set a value in the parent project from within a child library, you can pass a callback Action (Library Value of type Action) from the parent into the library. The library can then call this action whenever needed.

Event & Action Communication Between Modules

While App State & value-based Library Values help with data storage and retrieval, some interactions require triggering behavior across modules like refreshing a list, navigating, or performing calculations.

FlutterFlow provides two key patterns for cross-library event handling:

🔸 Action Blocks

• Logic flow is defined inside the dependency Library.
• The Consumer project calls the action.
• Ideal when the Library owns the behavior (e.g., placing an order, triggering payment).

🔸 Library Values (of Action type)

• Logic is defined in the Consumer project.
• The dependency Library project triggers the logic via callback.
• Ideal when the Library wants to "ask" the Hub to do something (e.g., notify parent that payment was completed)

Action Blocks vs Callback Library Values

ScenarioUseA Library wants to tell the parent something happened (e.g. order placed) so the parent can act on it.✅ Callback (Action Library Value)A parent wants to trigger something in the Library (e.g. trigger payment)✅ Action Block exposed by Library

Wrapping up...

Building a super app in FlutterFlow helps you creating a scalable, maintainable architecture where each module can evolve independently while still working together seamlessly.

FlutterFlow’s Library system allows you to:

• Encapsulate full feature modules like food delivery or hotel booking
• Share reusable logic with nested libraries like Payment or Auth
• Coordinate state and behavior through App State, Library Values, and callback Actions

By applying patterns like Hub & Spokes, you can keep your codebase modular, your teams unblocked, and your app experience smooth for users.