Розробка мультитенантного мобільного застосунку

Розробка мультитенантного мобільного застосунку

Ми розробляємо мультитенантні мобільні застосунки, де одна кодова база обслуговує декілька клієнтів (тенантів) з унікальним брендингом, даними та функціоналом. За 10+ років ми накопичили досвід реалізації таких архітектур для фінтеху, ритейлу та корпоративних платформ. Головне завдання — забезпечити повну ізоляцію даних і конфігурацій, а також гнучкість при додаванні нових тенантів. У цій статті розберемо основні підходи та їх вплив на продуктивність, безпеку і час виведення на ринок.

Два принципово різних підходи

Один бінарник, перемикання в рантаймі. Застосунок завантажує конфігурацію тенанта при запуску — кольори, логотип, 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 presence. Якщо кожному тенанту потрібен свій застосунок в сторі — другий підхід неминучий.

Порівняння підходів:

Чому ізоляція даних — критичний аспект?

Ізоляція даних — критичний аспект. Витік даних одного тенанта до іншого — катастрофа. На рівні мобільного застосунку:

tenant_id зберігається в Keychain (iOS) / EncryptedSharedPreferences (Android) при першому вході. Всі API-запити включають tenant-специфічний заголовок або subdomain (tenant-a.api.example.com). Локальна БД — або окрема SQLite-база на тенанта, або префіксування таблиць.

При зміні тенанта (якщо підтримується) — повне скидання локального кешу, очищення Keychain-записів, повторна аутентифікація. Не можна допустити ситуацію, коли UserRepository поверне дані від попереднього тенанта з кешу.

Ми гарантуємо ізоляцію на рівні коду та інфраструктури — кожен тенант використовує окремі credentials та keychain entries.

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 — single source of truth, всі компоненти звертаються тільки до нього. Флаги кешуються локально з TTL, оновлюються в фоні при запуску.

Як feature flags прискорюють адаптацію застосунку під клієнта?

За допомогою feature flags можна увімкнути або вимкнути функцію для конкретного тенанта без випуску нового білда. Це скорочує час релізу з тижнів до хвилин. Наприклад, якщо один клієнт просить приховати криптовалютний розділ, достатньо змінити флаг в конфігу — інші тенанти не зачеплені.

Тема (theming). У Flutter — ThemeData з кастомними ColorScheme та TextTheme, MaterialApp(theme: TenantTheme.fromConfig(config)). У React Native — Context з токенами через StyleSheet або styled-components. Динамічні шрифти — через @font-face (RN) або FontLoader (Flutter). Іконки — SVG з перефарбовуванням через colorFilter або спрайт-пак на тенанта.

Аутентифікація та авторизація

Кожен тенант може мати свій Identity Provider: один використовує власний SSO (OAuth 2.0 + PKCE), інший — корпоративний SAML через мобільний проксі, третій — просту email/password аутентифікацію. AuthStrategy — інтерфейс з реалізаціями під кожен тип. AppAuth (iOS/Android) для OAuth PKCE — стандарт, рекомендований RFC 8252 для мобільних клієнтів.

Як реалізувати аутентифікацію для різних Identity Providers?

Ми використовуємо абстрактну фабрику AuthStrategyFactory, яка на основі tenant ID повертає потрібну реалізацію. Це дозволяє підключати новий IdP без зміни основного коду. Тестування кожної стратегії ізольовано — витік токенів між тенантами виключено.

Кейс. White-label фінтех-платформа: 12 тенантів — банки та МФО. Один бінарник у Google Play, окремі IPA через Apple Business Manager для корпоративних клієнтів. Конфіг тенанта завантажується з CDN (CloudFront) при першому запуску та кешується в EncryptedSharedPreferences/Keychain з 24h TTL. Feature flags керують 23 функціями. Кожен тенант має ізольовану базу даних на бекенді, мобільний клієнт використовує tenant-subdomain для всіх запитів. Середній час додавання нового тенанта після налаштування інфраструктури — 4 години (створення конфігу + Fastlane lane + CI pipeline). Завдяки такому підходу платформа скоротила час виведення нового клієнта на ринок на 40% порівняно з монолітним застосунком.

Що входить в роботу

При замовленні розробки мультитенантного мобільного застосунку ви отримуєте:

• Архітектурний документ з вибором стратегії (один бінарник / окремі збірки).
• Налаштовану CI/CD-інфраструктуру (Fastlane, GitHub Actions, CodeMagic).
• CDN для конфігів та оновлень feature flags.
• Інтеграцію з tenant-specific Identity Provider.
• Код з тестами ізоляції даних.
• Інструкцію з додавання нового тенанта (playbook).
• Пост-релізну підтримку на 1 місяць.

Які терміни розробки мультитенантного застосунку?

Вартість розраховується індивідуально. Ключове питання при оцінці — кількість тенантів, відмінності в їхній бізнес-логіці та вимоги до App Store присутності.

Зв'яжіться з нами для консультації з архітектури вашого мультитенантного застосунку. Замовте розробку — отримайте надійне рішення з гарантією ізоляції та масштабування.