פיתוח אפליקציות מובייל מרובות דיירים

פיתוח אפליקציות מובייל מרובות דיירים (Multi-Tenant)

אנו מפתחים אפליקציות מובייל מרובות דיירים, שבהן קוד בסיס אחד משרת מספר לקוחות (דיירים) עם מיתוג, נתונים ופונקציונליות ייחודיים. עם ניסיון של 10+ שנים, יישמנו ארכיטקטורות כאלה עבור פלטפורמות פינטק, קמעונאות וארגונים. האתגר המרכזי הוא הבטחת בידוד מוחלט של נתונים ותצורות תוך שמירה על גמישות להוספת דיירים חדשים. מאמר זה מפרק את הגישות המרכזיות והשפעתן על ביצועים, אבטחה וזמן יציאה לשוק.

שתי גישות שונות מהותית

בינארי יחיד, מעבר בזמן ריצה. האפליקציה טוענת תצורת דייר בעת ההפעלה: צבעים, לוגו, דגלי תכונה, נקודת קצה API, טקסטים. המשתמש רואה "בנק א'" או "בנק ב'" בהתאם לקישור ששימש להתקנת האפליקציה או לדומיין שהוזן. טכנית: קישור עמוק או קוד QR עם מזהה דייר → TenantRepository טוען תצורת JSON מ-CDN → ThemeProvider מחיל טוקנים → FeatureFlagService מאפשר/משבית מסכים. APK/IPA אחד בחנות. חיסרון: המיתוג ב-App Store (צילומי מסך, אייקון) הוא אוניברסלי, לא ספציפי לדייר. Google Play מקבל זאת; App Store לא עבור B2C, אך מקובל עבור MDM ארגוני.

בינאריים נפרדים באמצעות אוטומציית בנייה. עבור כל דייר, נבנה APK/IPA נפרד עם applicationId/bundleIdentifier ייחודיים, אייקון, שם ותצורה. Fastlane Lanes + Build Flavors (אנדרואיד) + Xcode Schemes/Targets (iOS). הוספת דייר פירושה הוספת flavor חדש ב-flavor ו-Xcode target חדש — ללא שינויי קוד. CI בונה את כל הווריאנטים במקביל.

הבחירה תלויה בדרישות הנוכחות ב-App Store. אם כל דייר צריך רישום חנות משלו, הגישה השנייה היא בלתי נמנעת.

השוואת גישות:

מדוע בידוד נתונים הוא קריטי

בידוד נתונים הוא קריטי. דליפה של נתוני דייר אחד לדייר אחר היא קטסטרופלית. ברמת אפליקציית המובייל:

build.gradle.kts מאוחסן ב-Keychain (iOS) / EncryptedSharedPreferences (אנדרואיד) בכניסה הראשונה. כל בקשות ה-API כוללות כותרת או תת-דומיין ספציפיים לדייר (tenant_id). מסד נתונים מקומי — או מסד SQLite נפרד לכל דייר או קידומת טבלאות.

בעת מעבר בין דיירים (אם נתמך) — ניקוי מלא של מטמון מקומי, מחיקת רשומות Keychain, ואימות מחדש. אסור שמצב שבו tenant-a.api.example.com מחזיר נתונים שמורים במטמון מדייר קודם.

אנו מבטיחים בידוד הן ברמת הקוד והן ברמת התשתית — כל דייר משתמש באישורים ורשומות keychain נפרדות.

דגלי תכונה ותצורה

תצורת דייר היא יותר מעיצוב. מבנה טיפוסי:

{
  "tenant_id": "bank-a",
  "theme": {
    "primary": "#1A73E8",
    "logo_url": "..."
  },
  "features": {
    "transfers_enabled": true,
    "crypto_tab": false,
    "biometric_required": true
  },
  "api_base_url": "https://bank-a.api.example.com",
  "support_phone": "+7-800-...",
  "terms_url": "https://bank-a.example.com/terms"
}

דגלי תכונה שולטים בנראות של קטעי ניווט שלמים ובהתנהגות לוגיקה עסקית. UserRepository הוא מקור האמת היחיד; כל הרכיבים מתייחסים אליו בלבד. הדגלים נשמרים במטמון מקומי עם TTL ומתעדכנים ברקע בעת ההפעלה.

כיצד דגלי תכונה מאיצים התאמת אפליקציה ללקוח?

דגלי תכונה מאפשרים להפעיל או להשבית פונקציה עבור דייר ספציפי ללא שחרור בנייה חדשה. זה מקצר את זמן השחרור משבועות לדקות. לדוגמה, אם לקוח מבקש להסתיר את קטע הקריפטו, פשוט משנים את הדגל בתצורה — דיירים אחרים לא מושפעים.

עיצוב (Theming). ב-Flutter — { "tenant_id": "bank-a", "theme": { "primary": "#1A73E8", "logo_url": "..." }, "features": { "transfers_enabled": true, "crypto_tab": false, "biometric_required": true }, "api_base_url": "https://bank-a.api.example.com", "support_phone": "+7-800-...", "terms_url": "https://bank-a.example.com/terms" } עם FeatureFlagService ו-ThemeData מותאמים אישית, ColorScheme. ב-React Native — Context עם טוקנים דרך TextTheme או MaterialApp(theme: TenantTheme.fromConfig(config)). גופנים דינמיים — דרך StyleSheet (RN) או styled-components (Flutter). אייקונים — SVG עם צביעה מחדש דרך @font-face או חבילת sprite לכל דייר.

אימות והרשאות

כל דייר יכול להיות עם ספק זהות משלו: אחד משתמש ב-SSO ארגוני (OAuth 2.0 + PKCE), אחר משתמש ב-SAML ארגוני דרך פרוקסי מובייל, ושלישי משתמש באימות פשוט של אימייל/סיסמה. FontLoader — ממשק עם מימושים לפי סוג. colorFilter (iOS/אנדרואיד) עבור OAuth PKCE הוא התקן המומלץ על ידי RFC 8252 עבור לקוחות מובייל.

כיצד ליישם אימות עבור ספקי זהות שונים?

אנו משתמשים ב-AuthStrategy מופשט שמחזיר את המימוש הנכון לפי מזהה דייר. זה מאפשר חיבור ספק זהות חדש ללא שינוי קוד הליבה. כל אסטרטגיה נבדקת בבידוד — מניעת דליפת טוקנים בין דיירים.

מקרה בוחן. פלטפורמת פינטק White-label: 12 דיירים — בנקים וחברות מימון חוץ-בנקאי. בינארי אחד ב-Google Play, IPAs נפרדים דרך Apple Business Manager עבור לקוחות ארגוניים. תצורת הדייר נטענת מ-CDN (CloudFront) בהפעלה הראשונה ונשמרת במטמון ב-AppAuth/Keychain עם TTL של 24 שעות. דגלי תכונה שולטים ב-23 פונקציות. לכל דייר יש מסד נתונים מבודד בקצה העורפי; לקוח המובייל משתמש בתת-דומיין של הדייר עבור כל הבקשות. זמן ממוצע להוספת דייר חדש לאחר הקמת התשתית — 4 שעות (יצירת תצורה + Fastlane lane + צינור CI). גישה זו הפחיתה את זמן היציאה לשוק של הפלטפורמה עבור לקוחות חדשים ב-40% בהשוואה לאפליקציה מונוליטית.

מה כלול בעבודה שלנו

בהזמנת פיתוח אפליקציית מובייל מרובת דיירים, אתה מקבל:

• מסמך ארכיטקטורה עם בחירת אסטרטגיה (בינארי יחיד / בנייה נפרדת).
• תשתית CI/CD מוגדרת (Fastlane, GitHub Actions, CodeMagic).
• CDN עבור תצורות ועדכוני דגלי תכונה.
• אינטגרציה עם ספק זהות ספציפי לדייר.
• קוד עם בדיקות בידוד נתונים.
• מדריך (Playbook) להוספת דייר חדש.
• תמיכה לאחר שחרור למשך חודש אחד.

לוחות זמנים לפיתוח אפליקציה מרובת דיירים

העלות מחושבת באופן אישי. הגורמים המרכזיים הם מספר הדיירים, ההבדלים בלוגיקה העסקית ודרישות הנוכחות ב-App Store.

צור קשר לייעוץ על ארכיטקטורת האפליקציה מרובת הדיירים שלך. הזמן פיתוח וקבל פתרון אמין עם בידוד וסקלביליות מובטחים.