Multi-Tenant Mobile App Development

We develop multi-tenant mobile applications where a single codebase serves multiple clients (tenants) with unique branding, data, and functionality. With 10+ years of experience, we've implemented such architectures for fintech, retail, and enterprise platforms. The core challenge is ensuring complete isolation of data and configurations while maintaining flexibility for adding new tenants. This article breaks down the key approaches and their impact on performance, security, and time-to-market.

Two Fundamentally Different Approaches

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

Separate binaries via build automation. For each tenant, a separate APK/IPA is built with unique applicationId/bundleIdentifier, icon, name, and config. Fastlane Lanes + Build Flavors (Android) + Xcode Schemes/Targets (iOS). Adding a tenant means adding a new flavor in build.gradle.kts and a new Xcode target — no code changes. CI builds all variants in parallel.

Which to choose depends on App Store presence requirements. If each tenant needs its own store listing, the second approach is inevitable.

Comparison of approaches:

Why Data Isolation Is Critical

Data isolation is critical. Leaking one tenant's data to another is catastrophic. At the mobile app level:

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

When switching tenants (if supported) — full local cache flush, Keychain record cleanup, re-authentication. It must never happen that UserRepository returns cached data from a previous tenant.

We guarantee isolation at both code and infrastructure levels — each tenant uses separate credentials and keychain entries.

Feature Flags and Configuration

Tenant config is more than 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 entire navigation sections and business logic behavior. FeatureFlagService is the single source of truth; all components reference it only. Flags are cached locally with TTL and updated in the background at startup.

How feature flags speed up app adaptation for a client?

Feature flags let you enable or disable a function for a specific tenant without releasing a new build. This cuts release time from weeks to minutes. For example, if a client asks to hide the cryptocurrency section, just change the flag in the config — other tenants are unaffected.

Theming. In Flutter — ThemeData with custom ColorScheme and TextTheme, MaterialApp(theme: TenantTheme.fromConfig(config)). In React Native — Context with tokens via StyleSheet or styled-components. Dynamic fonts — via @font-face (RN) or FontLoader (Flutter). Icons — SVG with recolor via colorFilter or sprite pack per tenant.

Authentication and Authorization

Each tenant can have its own Identity Provider: one uses corporate SSO (OAuth 2.0 + PKCE), another uses corporate SAML via mobile proxy, a third uses simple email/password authentication. AuthStrategy — interface with implementations per type. AppAuth (iOS/Android) for OAuth PKCE is the standard recommended by RFC 8252 for mobile clients.

How to implement authentication for different Identity Providers?

We use an abstract AuthStrategyFactory that returns the correct implementation based on tenant ID. This allows plugging in a new IdP without changing core code. Each strategy is tested in isolation — token leakage between tenants is prevented.

Case study. White-label fintech platform: 12 tenants — banks and MFOs. One binary on Google Play, separate IPAs via Apple Business Manager for corporate clients. Tenant config is loaded from CDN (CloudFront) at first launch and cached in EncryptedSharedPreferences/Keychain with 24h TTL. Feature flags control 23 functions. Each tenant has an isolated backend database; the mobile client uses tenant-subdomain for all requests. Average time to add a new tenant after infrastructure setup — 4 hours (config creation + Fastlane lane + CI pipeline). This approach reduced the platform's time to market for new clients by 40% compared to a monolithic app.

What's Included in Our Work

When ordering development of a multi-tenant mobile app, you get:

• Architecture document with strategy selection (single binary / separate builds).
• Configured CI/CD infrastructure (Fastlane, GitHub Actions, CodeMagic).
• CDN for configs and feature flag updates.
• Integration with tenant-specific Identity Provider.
• Code with data isolation tests.
• Playbook for adding a new tenant.
• Post-release support for 1 month.

Timelines for Multi-Tenant App Development

Cost is calculated individually. The key factors are number of tenants, differences in business logic, and App Store presence requirements.

Contact us for a consultation on your multi-tenant app architecture. Order development and get a reliable solution with guaranteed isolation and scalability.