Розробка багатотенантного мобільного додатку
Багатотенантний мобільний додаток обслуговує кількох клієнтів (тенантів) з однієї кодової бази, кожен бачить свій брендинг, свої дані та потенційно свій набір функцій. Звучить просто. На практиці архітектурні рішення, прийняті на початку, визначають, наскільки болісно буде додавати десятого тенанта — або змінювати логіку для одного з існуючих.
Два принципово різних підходи
Один бінарник, переключення в runtime. Додаток завантажує конфігурацію тенанта при запуску — кольори, логотип, feature flags, API endpoint, тексти. Користувач бачить «Банк А» чи «Банк Б» залежно від посилання встановлення або введеного домену. Технічно: deep link або QR-код з tenant ID → TenantRepository завантажує JSON-конфіг з CDN → ThemeProvider застосовує токени → FeatureFlagService включає/вимикає екрани. Один APK/IPA в магазині. Мінус: брендинг App Store (скриншоти, іконка) — універсальний, не тенант-специфічний. Google Play це приймає; App Store — ні для B2C, але допустимо для корпоративного MDM.
Окремі бінарники через автоматизацію збірки. Для кожного тенанта собирається окремий APK/IPA з унікальним applicationId/bundleIdentifier, іконкою, назвою та конфігом. Fastlane Lanes + BuildFlavors (Android) + Xcode Schemes/Targets (iOS). Додавання тенанта — через новий flavor у build.gradle.kts та новий Xcode target — без змін кода. CI собирає всі варіанти паралельно.
Вибір залежить від вимог до App Store наявності. Якщо кожному тенанту потрібен свій додаток у магазині — другий підхід неминучий.
Архітектура даних та ізоляція
Ізоляція даних — критичний аспект. Витік даних одного тенанта до іншого — катастрофа. На рівні мобільного додатку:
tenant_id зберігається в Keychain (iOS) / EncryptedSharedPreferences (Android) при першому вході. Усі API-запити включають tenant-специфічний заголовок або поддомен (tenant-a.api.example.com). Локальна БД — або окремета SQLite-база на тенанта, або префіксування таблиць.
При змінах тенанта (якщо підтримується) — повний скид локального кеша, очищення Keychain-записів, повторна аутентифікація. Неможливо допустити ситуацію, коли UserRepository повернеш дані від попереднього тенанта з кеша.
Feature flags та конфігурація
Конфіг тенанта — більше ніж тема. Типова структура:
{
"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"
}
Feature flags управляють видимістю розділів навігації та поведінкою бізнес-логіки. FeatureFlagService — єдине джерело істини; всі компоненти звертаються тільки до нього. Флаги кешуються локально з TTL, оновлюються в фоні при запуску.
Брендування. Flutter: ThemeData з власним ColorScheme та TextTheme, MaterialApp(theme: TenantTheme.fromConfig(config)). React Native: Context з токенами через StyleSheet або styled-components. Динамічні шрифти: через @font-face (RN) або FontLoader (Flutter). Іконки: SVG з кольоровою фільтрацією або tenant-специфічний sprite sheet.
Аутентифікація та авторизація
Кожен тенант може мати власного Identity Provider: один використовує власний OAuth 2.0 + PKCE, іншій корпоративний SAML через мобільний прокси, третій просту email/password аутентифікацію. AuthStrategy інтерфейс з реалізаціями для кожного типу. AppAuth (iOS/Android) для OAuth PKCE — RFC 8252 стандарт для мобільних клієнтів.
Приклад. White-label фінтех-платформа: 12 тенантів — банки та МФО. Один Google Play бінарник, окремі IPA через Apple Business Manager для корпоративних клієнтів. Конфіг тенанта завантажується з CDN (CloudFront) при першому запуску, кешується в EncryptedSharedPreferences/Keychain з 24h TTL. Feature flags управляють 23 функціями. Кожен тенант має ізольовану базу даних на бекенді; мобільний клієнт використовує tenant-поддомен для всіх запитів. Середній час додавання нового тенанта після налаштування інфраструктури — 4 години (створення конфігу + Fastlane lane + CI pipeline).
Час реалізації
| Масштаб | Орієнтовні строки |
|---|---|
| Багатотенант із брендуванням, один бінарник | 10–16 тижнів |
| Окремі збірки на тенанта (flavor pipeline) | +3–5 тижнів до базової розробки |
| Складні feature flags + auth strategies | 5–9 місяців (повний продукт) |
Ціна розраховується індивідуально. Ключове питання при оцінці — кількість тенантів, різниці в їх бізнес-логіці та вимоги до App Store наявності.