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
| Approach | Time per Client | Error Probability | Scalability |
|---|---|---|---|
| Manual resource replacement | 3–7 days | High | Poor (linear growth) |
| Automation via Fastlane | 1–3 days | Low | Excellent (add client in minutes) |
Customization Checklist for a New Tenant
| Element | iOS | Android |
|---|---|---|
| App Icon | AppIcon.appiconset | mipmap + adaptive icon |
| Colors | Assets Color Set | colors.xml |
| Fonts | Info.plist + .ttf/.otf | res/font/ |
| Strings | Localizable.strings | strings.xml |
| Splash screen | LaunchScreen.storyboard | SplashScreen theme |
| Bundle ID / Package | Xcode Target settings | applicationId in flavor |
| Firebase config | GoogleService-Info.plist | google-services.json |
| Push entitlements | .entitlements | — |
| Deep link scheme | Info.plist URL Schemes | intent-filter |
| App Store metadata | Connect → App Information | Play Console |
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.