Разработка мобильных приложений
Клиент приходит с работающим прототипом на React Native, который начинает сыпаться при 10 000 DAU: список подтормаживает, push-уведомления приходят через раз, а release build на Android 14 падает с IllegalStateException при попытке открыть камеру. Продукт есть, но под нагрузкой он разваливается. Это типичная точка входа — не «хотим приложение с нуля», а «у нас есть что-то, что перестало справляться».
Мобильная разработка в 2024–2025 году — это не выбор между iOS и Android. Это архитектурные решения, которые принимают на старте и с которыми живут годами.
Нативная разработка: когда кроссплатформа не вариант
iOS-приложения на Swift и SwiftUI дают прямой доступ к HealthKit, ARKit, CoreML, StoreKit 2. Android на Kotlin с Jetpack Compose — к CameraX, WorkManager, ML Kit. Нативный стек оправдан, когда приложение завязано на платформенные API, требует максимальной производительности или работает с биометрией и Secure Enclave.
На практике нативная разработка выбирается для:
- Финтех-приложений с biometric authentication и работой с NFC (Apple Pay, Google Pay)
- Медицинских решений с интеграцией HealthKit / Google Fit
- AR-приложений на ARKit / ARCore
- Игр и интерактивных 3D на Metal / Vulkan
- Приложений, где критична анимация на 120 fps (ProMotion на iPhone 13 Pro+)
SwiftUI закрывает 80% UI-задач быстрее, чем UIKit, но UIKit никуда не ушёл — сложные кастомные ячейки, кастомные переходы, работа с UIScrollView на низком уровне. Реальные проекты используют оба фреймворка в одном приложении через UIHostingController и UIViewRepresentable.
На Android за последние два года Jetpack Compose стал production-ready. LazyColumn с remember и derivedStateOf рекомпозируется только там, где нужно — это принципиально другая модель против XML + RecyclerView с DiffUtil. Но Compose требует понимания: неправильно использованный State в LazyListScope гарантирует ненужные рекомпозиции и просадку FPS.
Flutter и React Native: где кроссплатформа выигрывает
Flutter рендерит UI через собственный движок Skia / Impeller — платформа не участвует в отрисовке. Это означает пиксельную точность на всех устройствах и отсутствие «платформенных» артефактов. Платформенные компоненты (Maps, Camera, WebView) подключаются через platform channels, что добавляет сложности, но не блокирует.
React Native использует нативные компоненты через JSI (JavaScript Interface). С появлением New Architecture (Fabric + TurboModules) синхронные вызовы из JS в нативный код стали работать без сериализации через JSON-мост. Это важно для анимаций и жестов — react-native-reanimated 3 теперь исполняет worklets прямо на UI thread.
Сравнение по ключевым параметрам:
| Критерий | Flutter | React Native | Нативный (iOS/Android) |
|---|---|---|---|
| Единый UI | Да (Skia/Impeller) | Нет (нативные виджеты) | Нет |
| Производительность | Близка к нативной | Зависит от JS thread | Максимальная |
| Время до рынка | Быстрее нативного | Быстрее нативного | Медленнее |
| Платформенные API | Через channels | Через modules/JSI | Прямой доступ |
| Размер команды | 1 команда | 1 команда | 2 команды |
| Экосистема | pub.dev (Dart) | npm (JS/TS) | Swift Package Manager / Maven |
KMM (Kotlin Multiplatform Mobile) решает другую задачу — не UI, а бизнес-логику. Shared-модуль на Kotlin компилируется в .framework для iOS и в Android-библиотеку. UI остаётся нативным на каждой платформе. Это рабочее решение для команд, у которых уже есть iOS и Android разработчики и которые хотят избавиться от дублирования логики (парсинг, кеширование, валидация).
UX/UI для мобайла: не просто Figma
Дизайн мобильного приложения — это не перенос веб-макета на маленький экран. iOS Human Interface Guidelines и Material Design 3 формируют ожидания пользователей от жестов, тайминга анимаций, плотности информации. Отступление от этих норм не «уникальный стиль» — это когнитивная нагрузка.
Прототипирование в Figma с Auto Layout и Component Properties позволяет собрать реалистичный интерактивный прототип до написания строчки кода. Разработчики получают design tokens — цвета, типографику, отступы — и импортируют их напрямую через Figma Variables API. Это сокращает количество итераций на этапе верстки.
Для проверки UX-гипотез до разработки используем Maze или UserTesting — тестируем конкретные сценарии на прототипе, не на готовом приложении.
Backend для мобильного приложения
Мобильный клиент потребляет API — REST или GraphQL. Выбор между ними не религиозный: GraphQL оправдан при сложной вложенной структуре данных и когда разные экраны запрашивают разные наборы полей одной сущности. REST с JSON:API или OpenAPI проще в кеше (HTTP cache headers) и мониторинге.
Для real-time — WebSocket (Socket.IO, native WS) или Server-Sent Events для однонаправленного потока. gRPC с protobuf — для high-throughput сценариев и внутренних микросервисов.
Push-уведомления через FCM (Firebase Cloud Messaging) и APNs (Apple Push Notification service). Прямая интеграция или через OneSignal / Braze — зависит от требований к сегментации аудитории и A/B-тестированию уведомлений.
Аналитика и мониторинг: что происходит после публикации
Firebase Crashlytics показывает crash-free rate — нормой считается 99,5%+. Ниже 99% — критично. Crashlytics группирует похожие крэши по stack trace и показывает, на каких устройствах и версиях ОС они концентрируются. Это первое, что настраиваем перед релизом.
Продуктовая аналитика — Firebase Analytics, Amplitude или Mixpanel. Воронки, retention, session duration. Важно не количество событий, а правильная таксономия: user_id, session_id, app_version, platform. Без этого данные не сегментировать.
Performance monitoring — Xcode Instruments (Time Profiler, Allocations, Leaks) для iOS, Android Profiler (CPU, Memory, Network, Energy) для Android. Для Flutter — DevTools с Timeline и Memory views.
AI в мобильном приложении: на устройстве или в облаке
CoreML на iOS позволяет запускать .mlmodel прямо на устройстве. YOLOv8, MobileNetV3, кастомные модели классификации — без сети, без задержки, без отправки данных на сервер. Convert2CoreML или coremltools конвертируют модели из PyTorch/TensorFlow.
На Android — TensorFlow Lite с ускорением через NNAPI (Neural Networks API) или ML Kit для готовых задач: распознавание текста, лиц, штрих-кодов, перевод.
LLM-интеграция — через API (OpenAI, Anthropic, Gemini) с потоковым ответом через SSE. На устройстве пока реально только небольшие модели (Phi-3-mini, Gemma 2B) — через llama.cpp с Metal/Vulkan backend.
Публикация в App Store и Google Play
App Store Review Guidelines — документ, который надо читать перед началом разработки, а не перед отправкой на ревью. Отклонения по 4.3 (Spam — приложение слишком похоже на другие), 2.1 (App Completeness — crashable demo), 3.1.1 (не реализован In-App Purchase там, где он требуется) — это недели потерянного времени.
Google Play менее строгий, но Play Integrity API с 2024 года стал обязательным для приложений, работающих с платёжными данными. MEETS_STRONG_INTEGRITY — требование для финтех.
Fastlane автоматизирует сборку, подписание и публикацию. match управляет сертификатами через git-репозиторий. CI/CD — GitHub Actions или Bitrise. Каждый merge в main — автоматическая сборка и отправка в TestFlight / Firebase App Distribution для тестирования.
Архитектура мобильного приложения: решения, которые сложно переделать
MVVM — базовый паттерн и для iOS (Combine + @Published), и для Android (ViewModel + StateFlow). BLoC на Flutter даёт предсказуемый поток событий: Event → BLoC → State. Clean Architecture добавляет слои (Data, Domain, Presentation) и делает бизнес-логику независимой от UI-фреймворка.
VIPER на iOS и TCA (The Composable Architecture) — для крупных приложений с большими командами, где важна изолированность фич и тестируемость каждого компонента.
Выбор архитектуры на старте определяет, насколько легко добавить feature через год и насколько сложно будет тестировать логику отдельно от UI.
Ориентиры по срокам
Сроки разработки зависят от сложности, наличия готового дизайна и бэкенда:
| Тип проекта | Ориентировочный срок |
|---|---|
| MVP (1 платформа, базовые фичи) | 6–10 недель |
| Полноценное приложение (2 платформы) | 3–6 месяцев |
| Сложный продукт с AI/AR/финтех | 6–12 месяцев |
| Редизайн и рефакторинг существующего | 4–8 недель |
Стоимость рассчитывается индивидуально после анализа требований — ТЗ, дизайн-макеты, описание интеграций.