Flutter Mobile

Composable, multi-repository Flutter platform for cross-platform mobile applications on iOS and Android.

What It Does

The Foundation’s Flutter platform is not a monolithic framework — it is a set of composable SDK packages (authentication, messaging, file handling, theming, and more) that you assemble to build their applications. The platform is organized across three layers:

sdks-flutter — The shared Foundation layer. A Melos-managed workspace of 25+ Dart packages providing core APIs, feature SDKs, and a UI component library.
Product SDKs — Domain-specific packages that build on sdks-flutter for a particular product vertical.
Product Apps — Final applications that compose Foundation and product SDKs into user-facing experiences.

Key Capabilities

Capability	Description
25+ Foundation Packages	Core APIs, feature SDKs, and shared UI in a single Melos workspace
Dependency Injection	Abstract `DependencyInjector` interface with pluggable implementations
SDK Initialization	Typed config-based factories that self-register all internal dependencies
Module Facades	Static facade classes that encapsulate DI, navigation, and screen entry per feature
SafeValueNotifier	Disposal-safe reactive primitives extending Flutter’s `ValueNotifier`
Either-Based Errors	`Either<Failure, T>` return types with a structured Failure hierarchy and Rollbar reporting
White-Label Theming	Runtime tenant theming from server configuration via `e11_tenant_bootstrap`
E11 UI Library	Comprehensive widget library (buttons, forms, dialogs, navigation, media, layout)
REST + Firestore	Dio-based REST clients with automatic auth headers, plus Firestore real-time streams
CI/CD	GitHub Actions pipelines deploying to TestFlight and Google Play

How It Fits Together


┌──────────────────────────────────────────────────────┐
│ Product Applications                                  │
│ Your product applications                             │
└──────────────────────┬───────────────────────────────┘
                       │
          ┌────────────▼────────────┐
          │ Product SDKs            │
          │ Domain-specific         │
          │ SDK packages            │
          └────────────┬────────────┘
                       │
┌──────────────────────▼───────────────────────────────┐
│ sdks-flutter (Foundation)                             │
│                                                       │
│ apis/              sdks/              ui/             │
│ ├─ e11_core        ├─ sdk_auth        ├─ ui          │
│ ├─ e11_infra       ├─ sdk_user        ├─ ui_charts   │
│ ├─ e11_rest        ├─ sdk_messaging   └─ ui_rich_text│
│ ├─ e11_firebase    ├─ sdk_files                      │
│ ├─ e11_platform    ├─ sdk_community                  │
│ ├─ e11_rollbar     ├─ sdk_notifications              │
│ └─ e11_tenant_     ├─ sdk_social                     │
│    bootstrap       ├─ sdk_access                     │
│                    ├─ sdk_search                      │
│                    ├─ sdk_registration                │
│                    ├─ sdk_config                      │
│                    ├─ sdk_customer                    │
│                    ├─ sdk_maps                        │
│                    ├─ sdk_events                      │
│                    ├─ sdk_content                     │
│                    └─ sdk_reporting                   │
└──────────────────────────────────────────────────────┘

Product apps depend on product SDKs, which depend on Foundation SDKs. The Foundation layer (sdks-flutter) is the truly reusable layer owned by the Engineering11 team.

Repository & Package Structure

sdks-flutter is a Dart workspace managed by Melos. Packages are organized into three directories:

Directory	Purpose	Packages
`apis/`	Core infrastructure — DI, error handling, logging, networking, Firebase, platform services	`e11_core`, `e11_infra`, `e11_platform`, `e11_rest`, `e11_firebase`, `e11_rollbar`, `e11_tenant_bootstrap`
`sdks/`	Feature SDKs — self-contained vertical slices with models, services, repositories, and optional UI	16 packages (`sdk_auth`, `sdk_user`, `sdk_messaging`, `sdk_files`, etc.)
`ui/`	Shared UI component library, charting, and rich text editing	`ui`, `ui_charts`, `ui_rich_text`


e11_core (base: DI interface, Either, Failure, Logger, utils)
│
├── e11_infra (GetX bindings, routing, key-value storage, toast)
├── e11_platform (device info, permissions, connectivity, deep links)
├── e11_rest (Dio REST client, Algolia search)
└── e11_firebase (Firestore, Auth, Cloud Messaging, Remote Config)
    │
    └── e11_tenant_bootstrap (white-label theming from server config)
ui (component library, theme system, navigation provider)
Feature SDKs depend on apis/ + ui as needed.

Architecture Patterns

Dependency Injection

e11_core defines an abstract DependencyInjector interface with put, lazyPut, find, and maybeFind operations. The default implementation (GetDependencyInjector in e11_infra) delegates to GetX’s service locator. A global di instance is created at app startup and threaded through SDK initialization.

di.put(() => MyService(...)) — eager, deduplicated
di.lazyPut(() => MyService(...)) — lazy with auto-recreation
di.find<MyService>() / di.maybeFind<MyService>() — resolve or return null

SDK Initialization

Each Foundation SDK exposes a static initialize factory that takes a typed config and registers all internal dependencies onto di:


final authSdk = AuthSdk.initialize(
  config: AuthConfig(
    di: di,
    appUserId: appUserId,
    serviceUrl: environment.authServiceUrl,
    errorHandler: errorHandler,
    logger: logger,
  ),
);

Product apps call these initializers during startup and resolve SDK services from di wherever needed.

Module Facade Pattern

Product apps organize features into static facade classes. Each module provides a dependencies(di) method that registers services, stores, and controllers, plus navigation methods (show, open) for entering its screens. Modules are wired into the app via route bindings callbacks, ensuring DI is set up before pages build.

PageNavigationRoute and a context.push(...) extension provide type-safe, declarative navigation. E11NestedNavigator creates isolated navigator stacks for tab-based UIs (e.g. Messaging, Network, and Communities tabs each with their own back stack).

Migration note: Navigation is being migrated to GoRouter for alignment with Flutter’s official routing recommendations.

What You Don’t Have to Build

Multi-package workspace management and dependency orchestration
Abstract dependency injection with pluggable implementations
Typed SDK initialization with self-registering dependencies
Disposal-safe reactive state primitives
Structured error handling with typed Failure hierarchies
REST client infrastructure with automatic auth headers and connectivity checks
Firestore real-time stream wrappers with permission-denied handling
White-label theming system with runtime tenant configuration
Comprehensive UI component library (50+ widgets)
CI/CD pipelines for TestFlight and Google Play deployment
Flutter version pinning and CI dependency resolution

What You Build

The Foundation provides the infrastructure — your team builds:

Product-specific UI screens and user workflows
Custom domain modules with feature-specific business logic
Business logic and orchestration in controllers and services
Branding, visual identity, and tenant-specific customization
Integration with product-specific backend services

Next Steps

Platforms Overview — Compare all frontend platforms
Frontend Overview — Return to the frontend overview
Architecture — Cross-platform architecture patterns
Backend Documentation — Understand the APIs your app will integrate with
Foundation Overview — See the complete platform capabilities