Разработка мультитенантного мобильного приложения

Разработка мультитенантного мобильного приложения

Мультитенантное мобильное приложение — это когда одна кодовая база обслуживает несколько клиентов (тенантов), каждый из которых видит свой брендинг, свои данные и потенциально свой набор функций. Звучит просто. На практике архитектурные решения, принятые в начале, определяют, насколько больно будет добавлять десятый тенант — или менять логику для одного из существующих.

Два принципиально разных подхода

Один бинарник, переключение в рантайме. Приложение загружает конфигурацию тенанта при запуске — цвета, логотип, 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 вернёт данные от предыдущего тенанта из кеша.

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, обновляются в фоне при запуске.

Тема (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 для мобильных клиентов.

Кейс. 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).

Сроки

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