White-Label Mobile App Development

White-Label Mobile App Development

Imagine: you have 10 clients, each needs their own app with unique branding but unified business logic. Without white-label, you risk drowning in code copying and errors, and the budget for maintaining multiple codebases can exceed the cost of the product itself. Our solution is a single codebase with parameterization that allows launching a new client in days. Typical savings when using white-label instead of building from scratch: 60-80% time and budget. Each client gets custom icons, colors, and content, while you get one repository and unified CI/CD. Our experience—50+ projects over 10+ years—guarantees a clean architecture from the first commit.

Order white-label app development and get a free initial audit of your current architecture.

For example, recently we launched a platform for a franchise network: five brands, each with its own color scheme and feature set, on a single codebase. Development costs were cut by 70%, time-to-market for a new brand was 10 days. In this article, we'll discuss architectural decisions, CI/CD, and common mistakes.

Why white-label approach is better than building from scratch?

A single repository means all logic is in one place; updates propagate to all clients. Customization without duplication is achieved via Product Flavors (Android) and Targets (iOS), which override only what differs. As a result, a new tenant launches in 1-2 weeks instead of 3-6 months. Scalability: adding a new client does not require rewriting code—just configure configs. More than 90% of the code remains common across all tenants.

Architectural Decisions

Product Flavors (Android) and Schemes/Targets (iOS)

The basic platform mechanism—Build Flavors on Android and Xcodeconfig/Targets on iOS—allows changing resources, string constants, and compiler flags without modifying code. As documented by Apple on Xcode Targets, each Target can have its own set of resources. On Android similarly, as described in the Product Flavors documentation.

Android: product flavors

// app/build.gradle.kts
android {
    flavorDimensions += "tenant"

    productFlavors {
        create("brandA") {
            dimension = "tenant"
            applicationId = "com.brandA.app"
            resValue("string", "app_name", "Brand A")
            buildConfigField("String", "API_BASE_URL", "\"https://api.brand-a.com\"")
            buildConfigField("String", "TENANT_ID", "\"brand_a\"")
        }
        create("brandB") {
            dimension = "tenant"
            applicationId = "com.brandB.app"
            resValue("string", "app_name", "Brand B")
            buildConfigField("String", "API_BASE_URL", "\"https://api.brand-b.com\"")
            buildConfigField("String", "TENANT_ID", "\"brand_b\"")
        }
    }
}

Resources (icons, colors, strings) are overridden via directories: app/src/brandA/res/drawable/ic_launcher.png and similarly for brandB.

iOS: Xcodeconfig + Multiple Targets

Each client gets a separate Target sharing the same code:

// Config.xcconfig
API_BASE_URL = https://api.brand-b.com
TENANT_ID = brand_b
FEATURE_PREMIUM_ENABLED = YES
FEATURE_CHAT_ENABLED = NO

Values from xcconfig are read into Info.plist and then into code.

Feature Flags per Tenant

Different clients often have different feature sets. Flags embedded in xcconfig/BuildConfig determine what gets compiled:

// Conditional compilation via BuildConfig
if (BuildConfig.FEATURE_PREMIUM_ENABLED) {
    setupPremiumFeatures()
}

For dynamic flags (changeable without recompilation), we use Firebase Remote Config with a project per tenant or a single project with tenant-specific parameters.

Theming Engine

Colors, fonts, spacing—not hardcoded in code but loaded from a Theme config:

// Android: AppTheme via theme attributes
data class TenantTheme(
    val primaryColor: Color,
    val accentColor: Color,
    val fontFamily: String,
    val cornerRadius: Float,
    val logoResId: Int
)

object ThemeProvider {
    fun getTheme(tenantId: String): TenantTheme = when (tenantId) {
        "brand_a" -> TenantTheme(
            primaryColor = Color(0xFF1A73E8),
            accentColor = Color(0xFFFB8C00),
            fontFamily = "Roboto",
            cornerRadius = 8f,
            logoResId = R.drawable.logo_brand_a
        )
        "brand_b" -> TenantTheme(/* ... */)
        else -> defaultTheme
    }
}

For React Native and Flutter, the architecture is similar but through Theme Context (RN) or ThemeData (Flutter).

How to Organize CI/CD for Multiple Artifacts?

Every push to main must build all tenant builds. On GitHub Actions:

strategy:
  matrix:
    flavor: [brandA, brandB, brandC]

steps:
  - name: Build APK for ${{ matrix.flavor }}
    run: ./gradlew assemble${{ matrix.flavor }}Release

  - name: Upload to Play Store
    uses: r0adkll/upload-google-play@v1
    with:
      serviceAccountJson: ${{ secrets.SERVICE_ACCOUNT_JSON }}
      packageName: com.${{ matrix.flavor }}.app
      releaseFiles: app/build/outputs/apk/${{ matrix.flavor }}/release/*.apk

Each flavor is deployed to a separate Play Store account or to one account with different Package Names. For iOS, use Fastlane with a scheme matrix.

How to Ensure Build Stability for Each Tenant?

Automated testing is critical: for each flavor in CI, run unit tests and UI tests on simulators. This prevents regressions when adding a new brand. We recommend keeping coverage >80% for modules with tenant logic.

Comparison of Approaches: Product Flavors vs Runtime Configuration

We recommend a hybrid: static resources via flavors, dynamic features via runtime flags.

Stages of White-Label App Development

Common Mistakes and How to Avoid Them

Tenant logic in business code. For example, if (tenantId == "brand_a") showSpecialButton() in ViewModel quickly leads to chaos. Correct: tenant-specific behavior through DI—inject strategies depending on flavor.

Shared strings with hardcoded brand names. The brand name should only be in the tenant directory. Use resources (strings.xml/Localizable.strings) for each brand separately.

Single Firebase project. Each tenant must have its own google-services.json, otherwise analytics and push notification conflicts arise.

Lack of auto tests for each flavor. Run tests for each flavor in CI. This is the only way to ensure a new brand doesn't break existing ones.

Typical tenant onboarding checklist: 1. Copy tenant directory template 2. Set icons, colors, strings 3. Create API keys and Firebase project 4. Add flavor to CI matrix 5. Test build and deploy.

What's Included

• Documentation: architecture diagram, instructions for adding a new tenant, description of CI/CD pipelines.
• Access: source code, repository, CI/CD configuration, store keys.
• Training: workshop for your team on working with white-label architecture.
• Support: 2-3 months after launch to resolve potential issues.

Time Estimates

MVP white-label app with 2-3 tenants on one platform (iOS or Android): 8-14 weeks. Cross-platform implementation with 5+ tenants and full CI/CD: 16-24 weeks. Cost is calculated individually after requirement analysis. Get a free consultation for your white-label project—contact us for an assessment.

White-Label Mobile Apps: SDK, Modular Architecture, and Multi-tenancy

In our practice, white-label development is not just "repainting an app." It is an architectural decision that must be made from the start. We have repeatedly encountered attempts to refactor a monolithic app into white-label post-factum — this is one of the most expensive refactorings in mobile development. Over 5 years of work, we have implemented 20+ white-label projects for iOS, Android, and cross-platform stacks. We guarantee: a proper modular architecture reduces the time to onboard a new client to 2 days, not 2 months. A white-label product is not just a logo change, but a full-fledged multi-tenant system. Get a consultation on white-label architecture — we will help you choose the right approach for your project.

What does "proper" modular architecture mean for white-label?

The key principle: no business logic module should know about a specific client. Configuration, colors, texts, feature flags — everything comes from outside via dependency injection, not hardcoded.

On iOS, the correct structure: Swift Packages for each domain (AuthKit, PaymentsKit, ProfileKit), a separate AppKit for the entry point, and BrandKit — a package with the specific client's theme. The main app is a thin wrapper that assembles them together.

// Wrong
class PaymentViewController: UIViewController {
    let primaryColor = UIColor(hex: "#FF5722") // hardcoded client A
}

// Correct
class PaymentViewController: UIViewController {
    let theme: AppTheme // injected at build time
}

On Android, the equivalent is Gradle multi-module with productFlavors. Each flavor builds the app for a specific client: substitutes google-services.json, theme, resources. One repository, multiple artifacts.

Theming: beyond colors and fonts

A superficial white-label — change colors and logo. This takes a day. Real customization — when a client can disable a module, change the order of onboarding screens, use their own payment provider.

In React Native for deep theming: ThemeProvider (React Context) at the top level, design tokens (colors.primary, spacing.md) via theme object, components get values only through tokens. For Flutter: ThemeData + ThemeExtension for custom tokens beyond Material Design.

Runtime theming (loading theme from the server) is a separate level of complexity. On iOS, UIAppearance proxy + manual update for existing views is unavoidable; SwiftUI with Environment and @EnvironmentObject for theme simplifies this significantly. According to App Store Review Guidelines Section 5.1.1, user data, including theme settings, must be processed with explicit consent.

Why multi-tenancy is critical for white-label

If multiple white-label apps use a shared backend, tenant identification at the API level is required. Option 1: X-Tenant-ID header in each request. Option 2: separate subdomains (clienta.api.example.com). Option 3: tenant from JWT token after authentication.

At the mobile app level: tenant ID is either hardcoded into the configuration at build time (via xcconfig / gradle.properties) or determined dynamically (by bundle ID or Remote Config). Dynamic determination is needed if one binary serves multiple clients — a rare but real enterprise case.

Savings from a multi-tenant architecture compared to dedicated backends are up to 60% on operational costs with 5+ clients.

How to properly design a white-label architecture?

A step-by-step approach we use:

1. Analysis — define domains that will be common to all clients and customization points.
2. Stack selection — for iOS: Swift Packages + XCFramework; for Android: Gradle multi-module + AAR; for cross-platform: Flutter/Dart package or React Native library.
3. Configuration design — JSON schema for brand (colors, fonts, feature flags, links), validation on the client.
4. Module implementation — each module publishes a protocol/interface; concrete implementation is injected via DI container (Swinject, Dagger Hilt).
5. Build automation — Fastlane + CI pipeline with CLIENT_ID parameter.
6. Testing — UI tests for each brand (screenshot testing with Percy or Firebase Test Lab).
7. Deployment — parallel upload to App Store Connect / Google Play Console via distributed builds.

SDK: when white-label is a library

If the product is embedded into other apps — it's an SDK, not a white-label app. Requirements are fundamentally different.

iOS SDK via Swift Package Manager: Package.swift describes the product, target, dependencies. Published via git tag. Critical: do not pull transitive dependencies unnecessarily — each SDK dependency potentially conflicts with the host app's dependencies.

Android SDK via Maven (Artifactory or GitHub Packages): AAR artifact with POM metadata. api() vs implementation() in gradle — export only what the client needs in api(). Everything internal — implementation().

SDK versioning via Semantic Versioning is mandatory. Breaking changes in minor version is death for a B2B product.

How to automate builds for a dozen brands

For 5+ white-label clients, manual builds are inefficient. Fastlane with lanes per client and shared methods is the baseline. A more mature solution: a parameterized CI pipeline where you pass CLIENT_ID and get a built IPA/APK/AAB for a specific brand.

Codemagic supports environment variables per workflow — convenient for multi-brand builds without a complex Fastfile.

Comparison of white-label approaches:

White-label based on productFlavors is 3–5 times faster when adding a new client than the fork approach, and reduces the risk of codebase divergence. Cost savings on maintaining 10 brands reach 70% compared to code copying.

What is included in the work

We provide white-label development turnkey:

• Architectural design — stack selection, modular breakdown, multi-tenancy scheme.
• Core functionality — authorization, profile, payment module (StoreKit 2 / Billing 6), push notifications (APNs / FCM), deep linking (Universal Links / App Links).
• Branding tools — theming, feature flags, screen configuration.
• Documentation — module description, build instructions, client guide.
• Access — repository, CI/CD, App Store Connect / Google Play Console.
• Training — 2–4 hours of demo for the client's team.
• Support — 1 month of warranty support after release.

Approximate timelines

Cost is calculated individually — depends on the number of modules, platforms, and depth of customization. Order a free analysis of your architecture — we will estimate the workload in 2 days. Contact us to discuss your white-label project — we guarantee compliance with App Store Review Guidelines and Google Play policies.