Разработка мобильного приложения для путешествий (TravelTech)
Бронирование авиабилета через мобильный браузер — это 12 экранов, которые пользователь должен пройти за 3 минуты до посадки в самолёт, стоя в очереди на паспортный контроль. Если на любом экране случится таймаут сессии, cold start после сворачивания приложения, или карта зависнет из-за недогруженных тайлов — он уйдёт к конкуренту. TravelTech-приложения не прощают нестабильности.
Что отличает travel-приложение от других вертикалей
Главная боль — гетерогенные внешние API с непредсказуемым SLA. Amadeus GDS возвращает ответ за 800 мс в лучшем случае, в пиковый сезон — за 4–6 секунд. Если показывать скелетон и блокировать весь экран, пользователь нажимает «назад» через 2 секунды. Правильное решение — прогрессивная загрузка: сначала отдаём кешированные результаты из Room/CoreData (прошлые поиски), параллельно запускаем свежий запрос, обновляем список через DiffUtil/diffableDataSource без перерисовки всего экрана.
Второй узкий момент — офлайн-режим. Турист в роуминге за границей с дорогим трафиком не может загрузить карту маршрута. Мы работаем с MapLibre GL Native и предзагружаем тайловые пакеты (.mbtiles) по региону перед поездкой — пользователь выбирает страну, скачивает ~40–120 МБ, и потом навигация работает без сети. На iOS это отлично сочетается с URLSession background transfer для фоновой загрузки во время зарядки.
Интеграция с системными Calendar API (EventKit на iOS, CalendarContract на Android) позволяет добавлять рейсы, брони отелей и туры прямо в системный календарь с глубокими ссылками обратно в приложение. Пользователи не замечают, насколько это удобно, пока это не ломается.
Бронирование и реальное время
Работа с booking-движками (Amadeus, Sabre, Travelport) или агрегаторами (TravelFusion, Duffel API) строится на polling или webhook-паттерне. Duffel предоставляет REST с хорошей документацией, Amadeus требует OAuth 2.0 и отдельного понимания их NDC-протокола. В обоих случаях результат поиска нужно хранить локально (encrypted SQLCipher или iOS Data Protection) — пользователь вернётся через 20 минут и ожидает увидеть тот же вариант.
Для push-уведомлений о смене статуса рейса используем Firebase Cloud Messaging (Android) и APNs (iOS) с content-available: 1 для silent push — приложение обновляет данные в фоне через BGAppRefreshTask без пробуждения пользователя.
Карты и маршруты
| Сценарий | Технология | Примечание |
|---|---|---|
| Онлайн-карта с POI | Google Maps SDK / MapKit | Готовые стили, быстрая интеграция |
| Офлайн-навигация | MapLibre GL Native | Открытый исходный, свои тайлы |
| Пешие маршруты | OpenRouteService API | Пешеходные, велосипедные профили |
| AR-путеводитель | ARKit / ARCore | Наложение POI на камеру |
AR-путеводители — отдельная история. На Android ARCore требует устройство с поддержкой Depth API для стабильного размещения объектов в пространстве. На старых Pixel 3 без LiDAR объекты «плавают» при движении. Это честно говорить клиенту на этапе проектирования.
Стек и архитектура
Для кроссплатформенных TravelTech-проектов чаще всего выбираем Flutter с BLoC или Riverpod. Причина прагматичная: Dart Isolates позволяют парсить большие JSON-ответы (списки рейсов на 500+ записей) вне main isolate без джанков в UI. На нативе Android — Kotlin Coroutines + Flow, iOS — Swift Concurrency с async/await. Архитектура — Clean Architecture с разбивкой на data/domain/presentation слои; это не религия, а необходимость, когда у вас 4 разных источника данных для одного экрана.
Локализация — отдельный модуль. Работаем с ICU message format через intl (Flutter) или Lokalise SDK. Даты, валюты и форматы телефонов не хардкодим — NumberFormat.currency(locale: userLocale) вместо ручного добавления символов.
Из практики
Проект: агрегатор туров для СНГ-рынка. Flutter, 3 платформы (iOS / Android / Web через Flutter Web). Главная проблема после запуска — OOM crash на Android при листании списка из 300+ туров с изображениями. Причина: Image.network без cacheWidth/cacheHeight загружал оригиналы 4K в память. Решение — CachedNetworkImage с явным memCacheWidth и lazy loading через flutter_staggered_grid_view с жёстким addRepaintBoundaries: true. После фикса потребление памяти упало с пиковых 380 МБ до 140 МБ на Redmi Note 10.
Этапы работы
- Аудит требований — разбираем, какие внешние API уже есть у клиента (GDS-контракты, партнёрские соглашения), что нужно интегрировать с нуля
- Проектирование архитектуры — схема данных, offline-first или online-first, стратегия кеширования
- UI/UX — Figma-прототип, согласование флоу бронирования
- Разработка — итерациями по вертикальным срезам (сначала поиск, потом бронирование, потом профиль)
- Тестирование — Appium для E2E, XCTest/Espresso для unit/integration, нагрузочное на API-интеграции
- Публикация — App Store Connect + Google Play Console, Fastlane для автоматизации
- Поддержка — мониторинг через Firebase Crashlytics + Sentry, A/B тесты через Firebase Remote Config
Сроки зависят от объёма: MVP с поиском рейсов и бронированием отелей — от 3 месяцев. Полноценный travel-суперапп с маршрутами, AR-функциями и офлайн-картами — 6–12 месяцев. Стоимость рассчитывается после детального анализа требований и аудита существующих API-контрактов.