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

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

Мы разрабатываем мультитенантные мобильные приложения, где одна кодовая база обслуживает несколько клиентов (тенантов) с уникальным брендингом, данными и функционалом. За 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 присутствию.

Свяжитесь с нами для консультации по архитектуре вашего мультитенантного приложения. Закажите разработку — получите надёжное решение с гарантией изоляции и масштабирования.