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

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

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

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

Архитектура мобильных приложений

Приложение собрано в одном ViewController на 2000 строк. Сетевые вызовы, бизнес-логика, обновление UI — всё в одном месте. Добавить новую фичу без регрессии сложно, написать тест невозможно. Это не «плохой код» — это отсутствие архитектуры. И это встречается чаще, чем можно ожидать, даже в production-приложениях с миллионом пользователей.

Мы проектируем архитектуру под ключ: от выбора паттерна до полной структуры проекта с тестами и документацией. За 7–10 дней получаете чистый модульный код, готовый к масштабированию.

Архитектурные паттерны в мобайле решают одну задачу: отделить UI от логики так, чтобы каждая часть была тестируемой и заменяемой.

MVVM: базовый паттерн

Model-View-ViewModel — стандарт для iOS (SwiftUI + Combine/async, UIKit + Combine) и Android (Jetpack ViewModel + StateFlow + Compose). ViewModel содержит состояние UI и бизнес-логику. View только отображает состояние и передаёт намерения пользователя в ViewModel. Model — данные и их источник.

Ключевое правило: ViewModel не знает об UIKit или Android View-классах. Нет импортов UIKit, нет Context-зависимостей (кроме Application context через Hilt). Это гарантирует тестируемость: ViewModel тестируется как чистый Kotlin/Swift-код без Android Instrumented Test.

MVVM закрывает 70% потребностей. Остальные 30% — где нужна строгая изоляция фич, масштабирование команды, сложный flow управления состоянием.

Clean Architecture: когда MVVM недостаточно

Добавляет слои поверх MVVM:

Domain-слой — бизнес-логика, независимая от платформы. UseCase (или Interactor) содержит одно бизнес-правило: GetUserOrdersUseCase, PlaceOrderUseCase. Зависит только от интерфейсов (protocol/interface), не от конкретных реализаций.

Data-слой — реализация репозиториев. OrderRepositoryImpl реализует OrderRepository из domain. Знает про Retrofit, Room, UserDefaults. ViewModel не знает, откуда данные — из сети или кеша.

Presentation-слой — ViewModel + View. Знает о Domain, не знает о Data.

Dependency rule: зависимости направлены только внутрь. Domain не зависит ни от чего. Data и Presentation зависят от Domain.

Presentation → Domain ← Data

Это даёт возможность подменять реализацию: тест использует in-memory репозиторий вместо сетевого, интерфейс остаётся тем же.

Практическая оговорка: Clean Architecture добавляет файлы и слои. Для небольшого приложения это overhead. Оправдан от ~15 фич и при команде 3+ разработчиков.

BLoC для Flutter: предсказуемый поток состояний

BLoC (Business Logic Component) — стандартный паттерн в Flutter-сообществе. Библиотека flutter_bloc реализует его через два типа: Bloc (Event → State) и Cubit (State без Events, только методы).

Bloc обрабатывает Event и эмитирует новый State через on<EventType> хендлеры. Состояние иммутабельно — новый объект на каждое изменение. BlocBuilder перерисовывает только ту часть дерева, где изменился state.

// Event
abstract class CartEvent {}
class AddItemToCart extends CartEvent {
  final String productId;
  AddItemToCart(this.productId);
}

// State
abstract class CartState {}
class CartLoaded extends CartState {
  final List<CartItem> items;
  CartLoaded(this.items);
}

// Bloc
class CartBloc extends Bloc<CartEvent, CartState> {
  CartBloc(this._cartRepository) : super(CartLoaded([])) {
    on<AddItemToCart>(_onAddItem);
  }

  Future<void> _onAddItem(AddItemToCart event, Emitter<CartState> emit) async {
    final current = state as CartLoaded;
    final updated = await _cartRepository.addItem(event.productId);
    emit(CartLoaded(updated));
  }
}

Преимущество BLoC — тестируемость. blocTest из bloc_test пакета позволяет проверить: при таком-то Event, с таким-то начальным State, BLoC должен эмитировать такой-то State. Без UI, без моков для Flutter-фреймворка.

VIPER: для крупных iOS-проектов

VIPER (View, Interactor, Presenter, Entity, Router) — наиболее строгое разделение обязанностей для iOS. Каждый компонент имеет протокол и конкретную реализацию.

• View — только UI, делегирует всё Presenter
• Interactor — бизнес-логика, работа с сетью и данными
• Presenter — посредник между View и Interactor, форматирует данные для View
• Entity — модели данных (чистые структуры)
• Router — навигация между модулями

Каждый модуль (экран или фича) — отдельный VIPER-модуль. Это исключает coupling между фичами и позволяет большим командам работать параллельно без конфликтов.

Цена: много файлов, много протоколов. Шаблонный код генерируется через Sourcery или кастомные Xcode-шаблоны. VIPER оправдан для приложений с 10+ разработчиками и 50+ экранами.

TCA (The Composable Architecture)

TCA от Point-Free — более современная альтернатива VIPER для iOS/macOS. Основные концепции: State (иммутабельное состояние фичи), Action (все возможные события), Reducer (State + Action → новый State + Effect), Store (хранит State, обрабатывает Actions).

Scope позволяет composable строить большие фичи из маленьких: родительский Reducer делегирует часть State дочернему. Каждая фича тестируется изолированно через TestStore с точным контролем над Effects.

TCA имеет крутую кривую обучения, но даёт предсказуемость, которую сложно получить другим способом: каждое изменение состояния — явный Action с конкретным источником.

Какой паттерн выбрать под вашу задачу?

Оценим проект за 1 день — подберём архитектуру с учётом размера команды, платформы и планов роста.

Универсального ответа нет. Архитектуру выбирают под размер команды, требования к тестируемости и горизонт поддержки приложения.

Что входит в нашу работу

• Аудит текущей архитектуры (если приложение уже существует) — выявим узкие места и регрессионные зоны.
• Проектирование модульной структуры с чёткими границами слоёв и правилами зависимостей.
• Создание каркаса проекта (Scaffold) с внедрением DI, организации папок и настройки линтеров.
• Написание юнит-тестов для слоя домена и ViewModel — минимум 80% покрытия ключевых use case.
• Подготовка документации — архитектурные диаграммы, README с правилами модификации кода, инструкция для онбординга новых разработчиков.
• Передача рабочего репозитория с CI-пайплайном (GitHub Actions / Bitrise), настроенным запуском тестов и статическим анализом.

Всё это входит в стоимость проектирования. Дополнительно — поддержка на этапе внедрения: консультации команды, code review первых pull request.

Что происходит без архитектуры

Типичный сценарий через 18 месяцев без архитектуры: 40% времени разработки уходит на дебаг регрессий. Новый разработчик разбирается в коде неделю перед тем, как сделать первый PR. Тесты не пишутся, «потому что сложно мокировать». Добавление новой фичи требует понимания половины кодовой базы.

Выбор архитектуры на старте — это инвестиция с возвратом через 3–6 месяцев. По нашим данным, правильно спроектированная архитектура с MVVM + Clean даёт в 3 раза меньше регрессий по сравнению с монолитным ViewController. А затраты на её внедрение окупаются за 2–3 спринта.

Согласно рекомендациям Apple по проектированию приложений, разделение ответственности — ключевой фактор устойчивости кода (https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/ImplementingaViewController.html).

Почему стоит доверить архитектуру профессионалам?

Неправильный выбор паттерна на старте ведёт к переписыванию половины кода через год. Мы видели десятки проектов, где попытка сэкономить на архитектуре оборачивалась многомесячным рефакторингом. У нас за плечами 10+ лет коммерческой разработки, опыт работы с приложениями от 1 до 50 разработчиков. Мы помогаем избежать типовых ошибок:

• Overengineering для простого MVP (назначаем MVVM, а не VIPER).
• Отсутствие dependency injection — подключаем Hilt/Koin/Dagger уже на старте.
• Игнорирование тестируемости — закладываем протоколы/интерфейсы с первого коммита.

Оценим ваш проект бесплатно — пришлите описание текущего приложения или идеи, и мы подберём оптимальную архитектуру за 1 день. Пишите в Telegram или на почту — в ответ вы получите архитектурную схему, план внедрения и смету.

Дополнительная таблица: сравнение затрат на внедрение

Время указано для команды из 2–3 разработчиков. С нашим шаблоном (generator) стартовый каркас готов за 1 день вне зависимости от выбранного паттерна.