Бронювання авіаквитка через мобільний браузер — це 12 екранів, які користувач має пройти за 3 хвилини до посадки, стоячи в черзі на паспортний контроль. Якщо на будь-якому екрані станеться таймаут сесії або карта зависне через недовантажені тайли — він піде до конкурента. TravelTech-додатки не прощають нестабільності. Ми — команда з 5+ років досвіду в цій ніші та 10+ реалізованих проєктів: від трекера рейсів до агрегатора турів. Гарантуємо архітектуру, яка витримує високі навантаження.
Чим 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 об'єкти «плавають» під час руху. Це чесно говорити клієнту на етапі проєктування.
Чому Flutter — оптимальний вибір для TravelTech?
Для кроссплатформних TravelTech-проєктів найчастіше обираємо Flutter з BLoC або Riverpod. Причина прагматична: Dart Isolates дозволяють парсити великі JSON-відповіді (списки рейсів на 500+ записів) поза main isolate без джанків в UI. Dart Isolates обробляють відповідь у 2–3 рази швидше, ніж стандартний async/await на React Native при однакових обсягах даних. На нативі 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) замість ручного додавання символів.
Порівняння підходів: offline-first vs online-first
| Параметр | Offline-first | Online-first |
|---|---|---|
| Швидкість відгуку UI | Миттєво (кеш) | Залежить від мережі |
| Споживання трафіку | Високе (попереднє завантаження) | Економія |
| Підходить для | Подорожі, метро, роумінг | Місто зі швидким інтернетом |
| Складність реалізації | Вища (синхронізація) | Нижча |
Оптимально — комбінований підхід: offline-first для карт та історії пошуку, online-first для актуальних цін.
З практики
Проєкт: агрегатор турів для СНД-ринку. 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-специфікація (OpenAPI), керівництво з розгортання
- Доступи: до репозиторію (GitHub/GitLab), CI/CD (Fastlane, GitHub Actions), магазинів додатків
- Навчання команди: воркшоп з архітектури та налаштування офлайн-режиму
- Підтримка після релізу: моніторинг Crashlytics, Sentry, A/B тести через Remote Config, SLA за критичними багами 24 години
Етапи роботи
- Аудит вимог — розбираємо, які зовнішні 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-контрактів.
Оцінимо ваш проєкт за 1 день — зв'яжіться з нами, щоб обговорити деталі. Замовте розробку travel-додатку, який не підведе в найвідповідальніший момент.