פיתוח אפליקציות מובייל ב-White-Label

פיתוח אפליקציות מובייל ב-White-Label

תארו לעצמכם: יש לכם 10 לקוחות, כל אחד צריך אפליקציה משלו עם מיתוג ייחודי אך לוגיקה עסקית אחידה. ללא white-label, אתם מסתכנים בטביעה בהעתקת קוד ושגיאות, והתקציב לתחזוקת מספר בסיסי קוד יכול לעלות על עלות המוצר עצמו. הפתרון שלנו הוא בסיס קוד יחיד עם פרמטריזציה המאפשרת השקת לקוח חדש תוך ימים. החיסכון האופייני בשימוש ב-white-label במקום בנייה מאפס: 60-80% זמן ותקציב. כל לקוח מקבל אייקונים, צבעים ותוכן מותאמים אישית, ואתם מקבלים מאגר אחד ו-CI/CD אחיד. הניסיון שלנו—50+ פרויקטים במשך 10+ שנים—מבטיח ארכיטקטורה נקייה מהקומיט הראשון.

הזמינו פיתוח אפליקציות white-label וקבלו אודיט ראשוני של הארכיטקטורה הנוכחית שלכם.

לדוגמה, לאחרונה השקנו פלטפורמה לרשת זכיינות: חמישה מותגים, כל אחד עם ערכת צבעים ומערכת תכונות משלו, על בסיס קוד יחיד. עלויות הפיתוח קוצצו ב-70%, זמן ההגעה לשוק למותג חדש היה 10 ימים. במאמר זה נדון בהחלטות ארכיטקטוניות, CI/CD וטעויות נפוצות.

למה גישת white-label עדיפה על בנייה מאפס?

מאגר יחיד פירושו שכל הלוגיקה במקום אחד; עדכונים מתפשטים לכל הלקוחות. התאמה אישית ללא שכפול מושגת באמצעות Product Flavors (אנדרואיד) ו-Targets (iOS), שמחליפים רק את מה ששונה. כתוצאה מכך, דייר חדש מושק תוך 1-2 שבועות במקום 3-6 חודשים. מדרגיות: הוספת לקוח חדש אינה דורשת שכתוב קוד—רק הגדרת קונפיגורציות. יותר מ-90% מהקוד נשאר משותף לכל הדיירים.

החלטות ארכיטקטוניות

Product Flavors (אנדרואיד) ו-Schemes/Targets (iOS)

מנגנון הפלטפורמה הבסיסי—Build Flavors באנדרואיד ו-Xcodeconfig/Targets ב-iOS—מאפשר שינוי משאבים, קבועי מחרוזות ודגלי קומפילציה ללא שינוי קוד. כפי שמתועד על ידי אפל בנושא Xcode Targets, לכל Target יכול להיות סט משאבים משלו. באנדרואיד באופן דומה, כמתואר בתיעוד Product Flavors.

אנדרואיד: 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/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\"") } } } ובאופן דומה עבור 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 נקראים לתוך app/src/brandA/res/drawable/ic_launcher.png ולאחר מכן לתוך הקוד.

Feature Flags לפי דייר

ללקוחות שונים יש לעיתים קרובות מערכות תכונות שונות. דגלים המוטמעים ב-xcconfig/BuildConfig קובעים מה יקומפל:

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

עבור דגלים דינמיים (ניתנים לשינוי ללא קומפילציה מחדש), אנו משתמשים ב-Firebase Remote Config עם פרויקט לכל דייר או פרויקט יחיד עם פרמטרים ספציפיים לדייר.

מנוע עיצוב (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 עבור מספר Artifacts?

כל push ל-main חייב לבנות את כל בנייני הדיירים. ב-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
---