White-Label App Customization for Client Branding

White-Label Mobile App Customization for Client Branding

You hand over a ready white-label app to a new client and immediately face the task of adapting it to their brand identity. Without proper resource architecture, replacing the logo, colors, and fonts turns into a multi-hour search for each hardcoded value. On one project, we counted 47 instances of the color #1A73E8 scattered across layout files. After refactoring to extract them into colors.xml, rebranding a new client took 2 hours instead of 3 days. With 5+ years of experience on 30+ white-label projects, we've developed a tenant-structure template that cuts rebranding time to 1–3 days.

Why the Standard Branding Approach Slows Down Launch

The typical mistake: colors hardcoded in layout files, brand name strings in code, fonts in properties. With every client change, developers spend hours searching and replacing. Automation via Fastlane makes rebranding 2–3 times faster than manual and eliminates errors.

Which App Elements Change During Rebranding

Visual Identity

App Icon. On iOS, you need icons in 15+ sizes for all devices and the App Store. The modern approach is one AppIcon.appiconset with a single 1024×1024 source image and auto-generation via Xcode or Fastlane appicon. On Android, use an adaptive icon (mipmap-anydpi-v26/ic_launcher.xml) with foreground and background layers: brand background + logo.

Color Scheme. All colors must be extracted into colors.xml (Android) or Assets.xcassets → Color Set (iOS). Direct hex values in layouts or code mean rebranding will take days instead of hours.

<!-- Android: res/values/colors.xml for a specific tenant -->
<resources>
    <color name="color_primary">#1A73E8</color>
    <color name="color_primary_variant">#1557B0</color>
    <color name="color_secondary">#FB8C00</color>
    <color name="color_surface">#FFFFFF</color>
    <color name="color_on_primary">#FFFFFF</color>
    <color name="color_error">#B00020</color>
</resources>

Fonts. The brand font is added via res/font/ (Android) or through Info.plist UIAppFonts (iOS). If the font is paid, check the license for mobile use (Desktop/Web licenses don't cover embedding in apps).

Texts and localization: All texts containing the brand name, slogans, or descriptions go into strings.xml / Localizable.strings in the tenant directory. No hardcoded strings in shared code. Splash screen text, onboarding texts, tab bar titles — all overridden without code changes.

Onboarding and Splash Screens: On iOS, implement splash via LaunchScreen.storyboard (or Launch Screen in Info.plist for SwiftUI). On Android, use the SplashScreen API (Android 12+) with branded icon and background:

// Android 12+ SplashScreen with brand color
installSplashScreen().apply {
    setKeepOnScreenCondition { viewModel.isLoading.value }
}

Splash theme:

<style name="Theme.App.SplashScreen" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/color_primary</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/ic_splash_logo</item>
</style>

How to Automate Rebranding with Fastlane

Manual resource replacement when adding each new tenant is error-prone. Fastlane action for applying branding:

# Fastfile
lane :apply_branding do |options|
  tenant = options[:tenant]
  brand_dir = "tenants/#{tenant}"

  # Copy resources
  sh "cp #{brand_dir}/AppIcon.png fastlane/metadata/#{tenant}/app_icon.png"
  sh "cp -r #{brand_dir}/assets.xcassets ios/MyApp/#{tenant}.xcassets"

  # Update Bundle ID
  update_app_identifier(
    xcodeproj: "ios/MyApp.xcodeproj",
    plist_path: "MyApp/Info.plist",
    app_identifier: "com.#{tenant}.app"
  )

  # Update Display Name
  update_info_plist(
    plist_path: "ios/MyApp/Info.plist",
    display_name: options[:display_name]
  )
end

fastlane apply_branding tenant:brand_b display_name:"Brand B"
fastlane ios build tenant:brand_b

Fastlane isn't the only option. Equivalent scripts can be written in Bash or Makefile. The key is a single entry point for all tenant resources.

Tip: When starting a new white-label project, create a dedicated tenant directory for each client. Store all changeable resources: icons, colors, fonts, strings, configs. This saves hours when adding the next client.

Comparison: Manual vs. Automated Branding

Customization Checklist for a New Tenant

What Our Customization Service Includes

When ordering the service, we prepare:

• Documentation: tenant directory scheme, instructions for adding a new client.
• Access: App Store Connect, Google Play Console, Firebase, TestFlight (your accounts).
• Training: a session for your QA to verify branding.
• Support: 2 weeks post-deploy — fixing visual inaccuracies.

Compare: building a white-label app from scratch for one client costs 5–10 times more than customizing an existing solution. When scaling to 10+ clients, resource savings exceed 80%.

Timeline Estimates

Customizing a ready white-label app for a new client with a properly set resource structure takes 1–3 days. If resources haven't been extracted into tenant directories and refactoring for multiple hardcoded instances is needed, it takes 3–7 days. Pricing is determined individually.

Contact us — we'll assess your project in 2 hours. We've worked with 30+ white-label projects on iOS and Android. Get a consultation for your case.

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.