Мобильная разработка
Mobile Architecture at Scale
Uber Eats: 50 инженеров, один монолитный iOS проект. Full build - 18 минут. Инженер тратит 2+ часа в день на ожидание. Решение: модуляризация на 40+ Swift Package. Full build остался 18 минут, incremental build - 90 секунд. Экономия: 1.5 часа в день на разработчика.
- Netflix iOS приложение: 200+ Swift модулей, отдельные команды владеют отдельными модулями - zero merge conflicts в core компонентах
- Airbnb: каждая фича за feature flag, 100% кода в main ветке - trunk-based development без long-lived feature branches
- Spotify: 99.97% crash-free rate как OKR для мобильной платформы - crash rate напрямую коррелирует с 7-day retention
Модуляризация: масштабируемая структура проекта
Монолитный iOS/Android проект с 200+ файлами: full rebuild при изменении одного файла - 10-15 минут. Модуляризация разделяет на Swift Package / Gradle modules по функциональному принципу. Изменение в feature/cart пересобирает только этот модуль и зависимые - 1-2 минуты.
- Core: общие утилиты, networking, analytics - нет зависимостей на другие модули
- DesignSystem: компоненты, цвета, типографика - зависит только от Core
- Feature модули: отдельные фичи (Cart, Profile, Search) - зависят от Core + DesignSystem
- App: собирает всё вместе, навигация между feature модулями
Главный практический бенефит модуляризации для команды разработки:
Feature Flags: безопасное развёртывание фич
Feature flag - runtime переключатель для включения/выключения функциональности без деплоя. Паттерны: release flags (постепенный rollout новой фичи), ops flags (emergency kill switch), experiment flags (A/B тест), permission flags (premium features).
LaunchDarkly, Firebase Remote Config, Statsig, Unleash - популярные feature flag платформы. Uber использует feature flags для постепенного rollout на водителей по гео-регионам. Airbnb: каждая новая фича запускается за flag - позволяет merge в main без риска, даже если фича не готова.
Зачем устанавливать default значения для feature flags при offline/ошибке?
A/B Testing: data-driven решения
A/B тест в мобильном приложении: разделить пользователей на группы, показать разные версии UI/логики, измерить метрики (конверсия, retention, revenue), выбрать победителя статистически. Ключевые компоненты: назначение в группу (deterministic по user ID), измерение, анализ.
Проблема мобильного A/B тестирования: App Store review занимает 1-3 дня. Без feature flags нельзя быстро остановить провальный тест. Решение: server-side experiment config с client-side feature flags. Booking.com проводит 1000+ A/B тестов одновременно; их мобильная команда показывает: персонализированная онбординг фотография увеличила конверсию на 8%.
Почему назначение пользователя в A/B группу должно быть детерминированным по userID?
Crash Reporting: мониторинг качества в production
Crash reporting = символизация stack trace + группировка похожих крашей + alerting. Firebase Crashlytics, Sentry, Bugsnag - популярные решения. Ключевые метрики: crash-free users %, crash rate по версиям, ANR (Application Not Responding) rate на Android.
Целевые метрики: crash-free users > 99.5% (промышленный стандарт), > 99.9% для финтех/медицина. ANR rate < 0.47% для рейтинга в Play Store (Google снижает видимость при превышении). Sentry дополнительно дает Session Replay и Performance Monitoring - просмотр сессии пользователя до краша.
Зачем добавлять пользовательский контекст (userID, plan, ab_variant) в crash reports?
Ключевые идеи
- Модуляризация: инкрементальная сборка - главный практический бонус для команды, не архитектурная чистота.
- Feature flags: merge в main сразу за флагом - trunk-based development без долгих веток, emergency kill switch.
- Crash reporting: crash-free users > 99.5% - стандарт индустрии. Контекст (userID, variant) ускоряет диагностику.
Связанные темы
Масштабируемая мобильная архитектура опирается на CI/CD и тестирование:
- Mobile CI/CD и Release — Feature flags и фазовый rollout работают вместе: flag включается постепенно через Play Console/ASC rollout
- Mobile на собеседовании (FAANG) — Модуляризация, feature flags, crash reporting - стандартные вопросы system design раунда в FAANG
Вопросы для размышления
- Как правильно чистить старые feature flags из кода: когда фича стала дефолтной для всех пользователей?
- В каком порядке организовывать модули: по слоям (data/domain/ui) или по фичам (cart/profile/search)?
- Как crash reporting помогает принимать решение об откате A/B эксперимента?