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.

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)

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.
• From your main app, you can also navigate into Level 2 Library pages, even if they're nested deeper in the dependency tree e.g., show the PaymentHistoryPage from PaymentLibrary that is imported by 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)

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:

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.

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.

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.

2. Library Values:

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

Library Values 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 consuming 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

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.