How to Build a White-Label Mobile App Platform for Agencies

Agencies have a revenue ceiling problem. They sell projects, deliver them, and then start over. A white-label mobile app platform breaks that cycle by letting agencies sell branded native apps to their clients on a recurring basis, without writing custom code for each one.

Think about it from the agency's perspective. A marketing agency with 200 restaurant clients could offer each one a branded iOS and Android app with online ordering, push notifications, and loyalty rewards. The apps look completely different on the surface, but underneath they all run on the same codebase. The agency charges $500/month per client, and their cost to serve each additional client is nearly zero after the platform is built.

This is exactly how companies like BuildFire, Glide, and GoHighLevel's mobile offering work. They provide a core platform, and resellers customize it per client. The difference between those platforms and what you can build is control. Off-the-shelf white-label tools force you into their feature set and pricing. Building your own means you own the roadmap, the margins, and the differentiation.

The technical challenge is real, though. You are not just building one app. You are building a system that produces an unlimited number of apps from a shared foundation. That means template engines, per-tenant configuration, automated native compilation, CI/CD pipelines that handle hundreds of app variants, and app store submission at scale. This guide covers every piece of that puzzle.

The first decision is your mobile framework, and for white-label platforms, it comes down to React Native or Flutter. Both can produce truly native apps from a single codebase, but they have different strengths when it comes to multi-tenant customization.

React Native for White-Label

React Native is the stronger choice for most white-label platforms, and the reason is JavaScript's dynamic nature. You can swap themes, load remote configuration, and change component behavior at runtime without recompiling the entire app. The React Native New Architecture (with Fabric and TurboModules) has closed the performance gap with Flutter, and the ecosystem is massive. Expo in particular has become a game-changer for white-label workflows. Expo Application Services (EAS) lets you define build profiles per client, each with different app icons, splash screens, bundle identifiers, and environment variables. One command, one config file, and you get a unique binary for each tenant.

The JavaScript bridge also means you can use over-the-air (OTA) updates via Expo Updates or CodePush to push content changes, bug fixes, and minor features to all tenant apps simultaneously without going through app store review. That alone saves agencies weeks of turnaround time per update cycle.

Flutter for White-Label

Flutter compiles to native ARM code, which gives it a slight edge on raw rendering performance and pixel-perfect UI consistency across devices. Its "flavors" system (Android product flavors and iOS build configurations) provides built-in support for generating multiple app variants from one project. You define a flavor per tenant with its own app ID, icons, and launch configuration, then build with flutter build apk --flavor clientA.

The downside is that Flutter's theming is compile-time heavy. While you can use runtime ThemeData objects, deeper customizations like changing native module behavior or swapping entire feature sets requires more boilerplate than React Native's dynamic approach. Flutter also lacks a mature OTA update equivalent, so every change, no matter how small, requires a full rebuild and app store submission.

For a detailed comparison of these frameworks across other dimensions, see our React Native vs. Flutter breakdown.

Our Recommendation

If your white-label platform prioritizes rapid tenant onboarding, OTA updates, and runtime flexibility, go with React Native plus Expo. If you need pixel-perfect custom UI rendering and your tenants rarely change configurations after initial setup, Flutter with flavors is solid. For agency platforms where clients constantly request tweaks, React Native wins.

The backbone of any white-label mobile platform is a configuration system that controls what each tenant's app looks like and how it behaves. This is not just a JSON file with colors. It is a full tenant manifest that drives everything from the app icon to which features are enabled.

What the Tenant Config Controls

Each tenant config should define at minimum:

• Brand identity: App name, bundle identifier (com.clientname.app), app icon set (six sizes for iOS, five for Android), splash screen image, and accent colors.
• Theme tokens: Primary, secondary, background, surface, error, and text colors. Font family and weight mappings. Corner radius values, spacing scale, and elevation/shadow presets.
• Feature flags: Which modules are enabled (e.g., loyalty program, in-app chat, booking system, push notifications). This lets you sell tiered packages to agency clients.
• API endpoints: Each tenant may point to different backend instances or different tenant-scoped API paths. Store base URLs, API keys, and webhook endpoints per tenant.
• App store metadata: App title, subtitle, description, keywords, screenshots, and privacy policy URL for both the App Store and Google Play.

Storage and Delivery

Store tenant configs in a centralized database (PostgreSQL works fine) with a management API. The agency admin panel lets operators create and edit configs through a visual interface. When a build is triggered, the CI/CD pipeline pulls the relevant config and injects it into the build process.

For runtime config (feature flags, theme changes that do not require a rebuild), serve a lightweight JSON payload from your API that the app fetches on launch. Cache it locally so the app works offline, and refresh it in the background. Firebase Remote Config does this well, but you can also build a simple endpoint that returns the tenant's current config keyed by their bundle ID.

One critical pattern: version your configs. When you ship a new app version that expects a config field that did not exist before (say, a new "chatEnabled" flag), older configs should not break the app. Use sensible defaults for every field and validate configs against a JSON schema before they enter the build pipeline.

Secrets Management

Tenant configs will contain sensitive values like API keys, push notification certificates, and App Store Connect credentials. Never store these in the same table as the display config. Use a secrets manager like AWS Secrets Manager, HashiCorp Vault, or Doppler. Your CI/CD pipeline should pull secrets at build time and inject them as environment variables, never baking them into the source code.

Building one app is straightforward. Building 200 branded variants from the same codebase on every release is an engineering problem that will define your platform's scalability. Your CI/CD pipeline is the single most important piece of infrastructure in a white-label mobile platform.

Pipeline Architecture

The pipeline works in three stages. First, the shared codebase is checked out and dependencies are installed once. Second, a build matrix fans out, creating one build job per tenant. Third, each job injects the tenant's config, compiles the native binary, signs it, and optionally submits it to the relevant app store.

With Expo EAS, this is surprisingly manageable. You define an eas.json file with build profiles per tenant. Each profile specifies the bundle identifier, build type (development, preview, production), and environment variables. A script iterates over your tenant registry and triggers eas build --profile tenant-slug --platform all for each one. EAS handles the actual compilation on their cloud infrastructure, so you are not managing macOS build agents yourself.

If you are not using Expo, you will need self-hosted or cloud CI runners. GitHub Actions with macOS runners works, but Apple silicon runners are expensive ($0.16/minute) and you will burn through minutes fast with hundreds of tenants. Bitrise and Codemagic are better options for mobile-specific CI because they offer dedicated macOS machines optimized for Xcode builds, with caching that dramatically reduces build times after the first run.

Build Optimization

Naive multi-tenant builds are slow. If you have 100 tenants and each build takes 15 minutes, a full release takes 25 hours of compute time. Here is how to cut that down:

• Dependency caching: Cache node_modules, CocoaPods, and Gradle dependencies across builds. The shared codebase is identical, so these caches have a near-100% hit rate.
• Incremental builds: Only rebuild tenants whose config has changed since the last release. Track config hashes and compare them before triggering a build.
• Parallel fan-out: Run tenant builds in parallel, not sequentially. EAS does this natively. On GitHub Actions, use a matrix strategy with your tenant list as the variable.
• Asset pre-processing: Generate tenant-specific app icons, splash screens, and asset catalogs in a preparation step before the native build. Tools like sharp for image resizing and appicon for generating icon sets can run in seconds.

Native Compilation Details

Each tenant build produces a truly separate native binary. On iOS, that means a unique .ipa file with its own bundle identifier, provisioning profile, and code signature. On Android, a unique .aab (Android App Bundle) with its own application ID and signing key. The native compilation step is where per-tenant config gets baked into the binary: the app name appears on the home screen, the icon is rendered by the OS, and the bundle ID determines how the app store identifies the app.

For React Native, the metro bundler compiles your JavaScript into a single bundle that gets embedded in the native shell. Tenant-specific static assets (icons, splash screens) replace the defaults during the build. For Flutter, the Dart compiler produces AOT-compiled native code, and flavors control which asset directories and configuration files are included.

White-label theming on mobile goes deeper than web theming. On the web, you swap CSS variables and call it a day. On mobile, you are dealing with OS-level components: status bars, navigation bars, system dialogs, splash screens, and widgets that all need to respect the tenant's brand.

Runtime Theme Injection

In React Native, create a ThemeProvider at the root of your component tree that reads from the tenant config. Every component pulls colors, typography, and spacing from this context. Libraries like React Navigation let you pass a custom theme object that controls the colors of headers, tab bars, and screen backgrounds. The key is making every visual property driven by the theme, never hardcoded.

For system-level elements, you need platform-specific handling. The status bar color is set via React Native's StatusBar component. The Android navigation bar color requires the react-native-navigation-bar-color package or a small native module. The splash screen is a static asset compiled into the binary, so it must be generated per tenant at build time (use react-native-bootsplash or expo-splash-screen with tenant-specific images).

Dark Mode per Tenant

Every tenant needs both a light and dark theme variant. Store both in the tenant config. Detect the user's system preference with useColorScheme() in React Native, then apply the appropriate variant. Some tenants will want to force light or dark mode regardless of the system setting, so include an "appearance" field in the config with options like "light," "dark," or "system."

Dynamic Fonts and Assets

Custom fonts are trickier than colors because they need to be loaded before any text renders. For build-time fonts, include the tenant's font files in the asset bundle during compilation. For runtime font loading (useful for OTA theme changes), use expo-font or react-native-dynamic-fonts to load fonts from a remote URL on app launch. Cache them locally after the first load to avoid flash-of-unstyled-text issues.

App icons and splash screens cannot be changed at runtime on iOS. They are baked into the binary. Android is slightly more flexible with adaptive icons, but practically speaking, both platforms require a rebuild to change the icon. This is why your CI/CD pipeline needs to be fast and reliable: agencies will request icon changes, and you need to turn those around quickly.

Widget and Extension Theming

If your platform supports iOS widgets (WidgetKit) or Android widgets (App Widgets), those also need tenant branding. Widgets run in a separate process from the main app, so they need their own access to the theme config. On iOS, share the config via an App Group container. On Android, use SharedPreferences accessible by the widget provider. This is a detail that many white-label platforms skip, but branded home screen widgets are a premium feature that agencies love to upsell.

Two of the most operationally painful parts of running a white-label mobile platform are push notifications and app store submissions. Both become nightmares at scale if you do not automate them from day one.

Push Notification Architecture

Each tenant app has its own bundle identifier, which means each one needs its own push notification credentials. On iOS, that is an APNs key or certificate per tenant. On Android, each app needs its own Firebase project (or at least a separate Firebase app within a shared project) with its own server key.

Managing this manually for 50+ tenants is unsustainable. Instead, build an automated provisioning flow: when a new tenant is created, your platform programmatically creates a Firebase app (via the Firebase Admin SDK), generates the necessary credentials, and stores them in your secrets manager. For APNs, use a single Apple Developer account with a key-based authentication (.p8 key), which works across all apps under that account without per-app certificates.

For the actual notification delivery, use a service like OneSignal, Knock, or Amazon SNS that supports multi-app management via API. OneSignal lets you create "apps" programmatically and send notifications scoped to a specific app ID. Your backend sends a notification request with the tenant's OneSignal app ID, and the service handles delivery through the correct APNs/FCM credentials.

Alternatively, build your own notification service using Firebase Cloud Messaging's multi-sender pattern, where a single server can send to multiple Firebase projects. This gives you more control but requires more infrastructure. For most platforms, a managed service like OneSignal is the right call until you pass 100 tenants.

App Store Submission Automation

Submitting one app to the App Store involves filling out metadata, uploading screenshots, setting privacy declarations, and waiting for review. Now multiply that by 100 tenants, for both iOS and Android. Without automation, you will need a full-time person just doing submissions.

Fastlane is the industry standard for automating mobile app deployment. For iOS, fastlane deliver uploads your .ipa, sets metadata (title, description, keywords), uploads screenshots, and submits for review. For Android, fastlane supply does the same for Google Play. The magic is that Fastlane reads all metadata from a directory structure, so you can generate per-tenant metadata directories from your tenant configs.

The workflow looks like this: your CI/CD pipeline builds the tenant's binary, then a post-build step runs Fastlane with the tenant's metadata directory, App Store Connect API key, and signing credentials. For App Store Connect authentication, use the App Store Connect API (introduced by Apple as a replacement for session-based auth) with per-tenant or shared API keys.

Screenshot generation is its own challenge. Each tenant needs localized screenshots showing their branded app. Tools like Fastlane Snapshot (for iOS) and Screengrab (for Android) can automate screenshot capture, but you need a running simulator/emulator with the tenant's config loaded. For efficiency, use a tool like FrameIt to overlay device frames onto screenshots, or generate synthetic screenshots from your design templates using a headless browser with Puppeteer. If your budget allows, factor screenshot automation into your mobile app development costs from the start.

Building the platform is half the equation. The other half is structuring your business model so both you (the platform owner) and your agency partners make money sustainably.

Revenue Models That Work

The most common model is a wholesale/retail markup. You charge agencies a per-app monthly fee ($50 to $200 per tenant app depending on features), and they charge their end clients $300 to $1,000 per month. The agency keeps the spread. This aligns incentives: agencies are motivated to sell more apps because each one is pure margin after a certain scale.

Tiered feature packaging amplifies this. Offer three or four tiers based on which modules are enabled in the tenant config. A basic tier might include branding, push notifications, and a content feed. A premium tier adds booking, e-commerce, loyalty programs, and analytics. Agencies love tiers because they create natural upsell conversations with their clients.

Some platforms also charge setup fees ($500 to $2,000) for initial tenant onboarding, which covers the time to configure branding, set up the app store listing, and do the first submission. This front-loads revenue and filters out clients who are not serious.

Unit Economics

The beauty of white-label is that your marginal cost per new tenant is almost zero. The codebase is shared. The CI/CD pipeline handles builds automatically. Push notification infrastructure scales linearly with a managed provider. Your real costs are:

• Apple Developer Program: $99/year per account. You can host hundreds of apps under one account, or agencies can use their own accounts.
• Google Play Developer: $25 one-time fee per account.
• CI/CD compute: Build minutes on EAS, Codemagic, or your own runners. Budget $0.02 to $0.05 per build minute.
• Push notifications: OneSignal is free up to 10,000 subscribers, then roughly $10/month per 10,000 additional subscribers per app.
• Hosting and API: Your backend costs scale with total end users across all tenants, not with the number of tenants. A well-optimized API on Railway or Fly.io can serve 50 tenant apps for under $100/month.

At 50 tenants paying $150/month wholesale, you are generating $7,500/month in recurring revenue with infrastructure costs under $500. That is 93% gross margin. At 200 tenants, the math gets even better because infrastructure costs grow sublinearly.

Agency Enablement

Your platform is only as successful as your agency partners. Give them a white-labeled admin dashboard where they can onboard new clients, configure branding, manage push notifications, and view analytics across all their tenant apps. Include a reseller API so technically sophisticated agencies can integrate tenant management into their existing workflows. If you are also building the web side, our guide to white-label SaaS covers the admin dashboard and reseller billing patterns in detail.

Documentation, onboarding videos, and a dedicated Slack channel for agency partners are not optional. The agencies selling your platform are not developers. They need clear instructions on how to collect branding assets from clients, how long the app store review process takes, and how to handle common rejection reasons. The better you enable your partners, the more apps they sell, and the more revenue you both earn.

If you are ready to build a white-label mobile app platform for your agency or your agency partners, we have helped teams architect and ship multi-tenant mobile platforms from the ground up. Book a free strategy call and we will map out the architecture, timeline, and costs specific to your use case.