Розробка White-Label мобільного додатку

Уявіть: у вас 10 клієнтів, кожному потрібен свій додаток з унікальним брендингом, але єдиною бізнес-логікою. Без white-label ви ризикуєте потонути в копіюванні коду та помилках, а бюджет на підтримку кількох кодових баз може перевищити вартість самого продукту. Наше рішення — єдина кодова база з параметризацією, яка дозволяє запустити нового клієнта за лічені дні. Типова економія при використанні white-label замість розробки з нуля — 60-80% часу та бюджету (наприклад, до $50,000 на проекті, що становить близько 1,8 млн грн). Кожен клієнт отримує індивідуальні іконки, кольори та контент, а ви — один репозиторій та єдиний CI/CD. Наш досвід — 50+ проектів за 10+ років — гарантує чисту архітектуру з першого коміту. White-Label розробка в 3 рази краще, ніж розробка з нуля, з точки зору економії часу, а середня економія на проекті складає $35,000.

Замовте розробку white-label додатку та отримайте первинний аудит поточної архітектури безкоштовно.

Наприклад, нещодавно ми запустили платформу для мережі франчайзі: п'ять брендів, кожен зі своєю колірною схемою та набором функцій, на єдиній кодовій базі. Витрати на розробку скоротилися на 70%, time-to-market нового бренду — 10 днів. White-label підхід у 4 рази швидше, ніж розробка з нуля. У цій статті розберемо архітектурні рішення, CI/CD та типові помилки.

White-Label розробка: ключові аспекти

Переваги White-Label розробки перед розробкою з нуля

White-label дозволяє запускати нових клієнтів у 3-5 разів швидше, ніж розробка з нуля. Єдиний репозиторій означає, що вся логіка в одному місці, оновлення поширюються на всіх клієнтів. Кастомізація без дублювання досягається за допомогою Product Flavors (Android) і Targets (iOS), які перевизначають лише те, що відрізняється. Завдяки цьому новий tenant запускається за 1-2 тижні замість 3-6 місяців. Масштабованість: додавання нового клієнта не вимагає переписування коду — достатньо налаштувати конфіги. Понад 90% коду залишається спільним для всіх tenants.

Архітектурні рішення

Product Flavors (Android) та Schemes/Targets (iOS)

Базовий механізм платформ — Build Flavors на Android та Xcodeconfig/Targets на iOS — дозволяє змінювати ресурси, рядкові константи та флаги компілятора без зміни коду. Як зазначено в документації Apple по Xcode Targets(https://developer.apple.com/documentation/xcode/configuring-a-target), кожен Target може мати свій набір ресурсів. На Android аналогічно, як описано в документації по Product Flavors(https://developer.android.com/studio/build/build-variants#product-flavors).

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\"") } } } 

Ресурси (іконки, кольори, рядки) перевизначаються через директорії: app/src/brandA/res/drawable/ic_launcher.png та аналогічно для brandB.

iOS: Xcodeconfig + Multiple Targets Кожен клієнт — окремий Target зі спільним кодом:

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

Значення з xcconfig читаються в Info.plist і далі в коді.

Feature Flags per Tenant

Різні клієнти часто мають різний набір функцій. 90% функцій спільні, 10% tenant-specific. Прапорці, зашиті в xcconfig/BuildConfig, визначають, що компілюється:

// Умовна компіляція через BuildConfig if (BuildConfig.FEATURE_PREMIUM_ENABLED) { setupPremiumFeatures() } 

Для динамічних прапорців (змінюваних без перекомпіляції) використовуємо Firebase Remote Config з проектом per tenant або єдиним проектом з tenant-specific параметрами.

Theming Engine

Кольори, шрифти, розміри відступів — не хардкодимо в код, а завантажуємо з Theme-конфігу:

// Android: AppTheme через 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 } } 

Для React Native та Flutter архітектура аналогічна, але через Theme Context (RN) або ThemeData (Flutter).

Як організувати CI/CD для множини артефактів?

Кожен push у main повинен збирати всі tenant-збірки. На 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