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:
- Analysis — define domains that will be common to all clients and customization points.
- Stack selection — for iOS: Swift Packages + XCFramework; for Android: Gradle multi-module + AAR; for cross-platform: Flutter/Dart package or React Native library.
- Configuration design — JSON schema for brand (colors, fonts, feature flags, links), validation on the client.
- Module implementation — each module publishes a protocol/interface; concrete implementation is injected via DI container (Swinject, Dagger Hilt).
- Build automation — Fastlane + CI pipeline with CLIENT_ID parameter.
- Testing — UI tests for each brand (screenshot testing with Percy or Firebase Test Lab).
- 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.
Typical mistakes when developing a white-label SDK
- Lack of backward compatibility at the API level (breaking changes in patch version).
- Using internal types in public methods (violating encapsulation).
- Tight coupling to a specific DI library of the host app.
- Insufficient setup documentation (how to sign XCFramework, how to add AAR to Gradle).
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:
| Approach | Implementation complexity | Customization flexibility | Time to onboard a new brand |
|---|---|---|---|
| Fork repository | Low (2–3 days) | Minimal (code copy) | 1–2 days |
| Feature flags + configs | Medium (2–4 weeks) | Medium (colors, texts, modules) | 2–4 hours |
| Multi-module / productFlavors | High (1–2 months) | High (any logic) | 30 minutes |
| SDK + white-label wrapper | Very high (2+ months) | Maximum (embedding into other apps) | 1–2 days |
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
| Task type | Timeline |
|---|---|
| Refactoring a monolith into white-label architecture | 2–3 months |
| New white-label app from scratch (iOS / Android) | 3–4 months |
| Mobile SDK development | from 6 weeks (simple), from 3 months (full-featured) |
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.