Multi-Tenant Mobile App Development

Multi-Tenant Mobile App Development

Multi-tenant mobile apps serve multiple clients (tenants) from one codebase, each seeing their branding, data, and potentially their feature set. Sounds simple. In practice, early architecture decisions determine how painful adding the tenth tenant will be—or changing logic for one existing tenant.

Two Fundamentally Different Approaches

Single binary, runtime switching. App loads tenant configuration on startup—colors, logo, feature flags, API endpoint, text. User sees "Bank A" or "Bank B" depending on installation link or domain entered. Technically: deep link or QR-code with tenant ID → TenantRepository loads JSON config from CDN → ThemeProvider applies tokens → FeatureFlagService enables/disables screens. Single APK/IPA in store. Downside: App Store branding (screenshots, icon) is universal, not tenant-specific. Google Play accepts this; App Store—not for B2C, but allowed for corporate MDM.

Separate binaries via build automation. Each tenant gets unique APK/IPA with unique applicationId/bundleIdentifier, icon, name, config. Fastlane Lanes + BuildFlavors (Android) + Xcode Schemes/Targets (iOS). Add tenant via new flavor in build.gradle.kts and new Xcode target—no code change. CI builds all variants in parallel.

Choice depends on App Store presence requirements. If each tenant needs its own store listing—second approach is required.

Data Architecture and Isolation

Data isolation—critical. One tenant's data leaking to another is catastrophic. At mobile app level:

tenant_id saved in Keychain (iOS) / EncryptedSharedPreferences (Android) on first login. All API requests include tenant-specific header or subdomain (tenant-a.api.example.com). Local database—either separate SQLite per tenant or table prefixing.

On tenant switch (if supported)—full local cache reset, Keychain record clearing, re-authentication. Can't allow UserRepository returning previous tenant's cached data.

Feature Flags and Configuration

Tenant config exceeds theming. Typical structure:

{
  "tenant_id": "bank-a",
  "theme": { "primary": "#1A73E8", "logo_url": "..." },
  "features": {
    "transfers_enabled": true,
    "crypto_tab": false,
    "biometric_required": true
  },
  "api_base_url": "https://bank-a.api.example.com",
  "support_phone": "+7-800-...",
  "terms_url": "https://bank-a.example.com/terms"
}

Feature flags control visibility of navigation sections and business logic behavior. FeatureFlagService is single source of truth; all components query only it. Flags cached locally with TTL, updated in background on startup.

Theming. Flutter: ThemeData with custom ColorScheme and TextTheme, MaterialApp(theme: TenantTheme.fromConfig(config)). React Native: Context with tokens via StyleSheet or styled-components. Dynamic fonts: via @font-face (RN) or FontLoader (Flutter). Icons: SVG with color filter or tenant-specific sprite sheet.

Authentication and Authorization

Each tenant may have own Identity Provider: one uses custom OAuth 2.0 + PKCE, another enterprise SAML via mobile proxy, third simple email/password. AuthStrategy interface with implementations per type. AppAuth (iOS/Android) for OAuth PKCE—RFC 8252 standard for mobile clients.

Case study. White-label fintech platform: 12 tenants—banks and microfinance orgs. Single Google Play binary, separate IPA's via Apple Business Manager for corporate clients. Tenant config loaded from CDN (CloudFront) on first launch, cached in EncryptedSharedPreferences/Keychain with 24h TTL. Feature flags manage 23 features. Each tenant has isolated database backend; mobile client uses tenant-subdomain for all requests. Average new tenant addition time after infrastructure setup—4 hours (config creation + Fastlane lane + CI pipeline).

Timeline

Pricing calculated individually. Key assessment question: tenant count, business logic differences, App Store presence requirements.