Типовий проект мобільного додатку для турагентства починається з бажання «зробити як у конкурента», але швидко впирається в технічні складнощі: інтеграція з GDS-системами, холдування місць, динамічні ціни та вимоги App Store. Особливо гостро стоїть проблема швидкості пошуку — XML API туроператорів (TUI, Coral Travel, Anex Tour) відповідають 5–15 секунд, а користувач мобільного додатку очікує результат за 2–3 секунди. Якщо не вирішити цю задачу архітектурно, відмови досягають 40%. Ми за 5+ років розробили 20+ проектів для туристичного бізнесу і знаємо, як обійти ці граблі.
Як прогресивне завантаження прискорює пошук в 5 разів
Крупні російські туроператори надають XML API за протоколом TourVisor або власним WSDL. XML-over-HTTPS з синхронними запитами — це legacy, яке диктує архітектуру: мобільний клієнт робить запит на свій бекенд, який паралельно опитує кількох постачальників, нормалізує результати і віддає єдиний JSON.
// Прогресивне завантаження результатів через WebSocket class SearchViewModel: ObservableObject { @Published var results: [TourPackage] = [] @Published var isSearching = false private var webSocketTask: URLSessionWebSocketTask? func startSearch(params: SearchParams) { isSearching = true results = [] webSocketTask = URLSession.shared.webSocketTask(with: searchStreamURL(params)) webSocketTask?.resume() receiveResults() } private func receiveResults() { webSocketTask?.receive { [weak self] result in switch result { case .success(.string(let json)): if let tour = TourPackage.decode(from: json) { DispatchQueue.main.async { self?.results.append(tour) } self?.receiveResults() } case .success(.data): break case .failure: DispatchQueue.main.async { self?.isSearching = false } @unknown default: break } } } } Прогресивне завантаження через WebSocket — альтернатива очікуванню всіх постачальників. Користувач бачить перші варіанти через 2–3 секунди, решта підвантажуються. За нашою статистикою, це знижує відмови на 30% і збільшує конверсію в бронювання на 15%. Порівняйте: традиційний підхід (дочекатися всіх) — швидкість пошуку в 5 разів нижча.
Чому кешування Redis економить бюджет на API
Пошук за напрямком, датами вильоту, харчуванням і зірковістю — стандартний набір. Складніше гнучкі дати «±3 дні», які множать кількість запитів до API. На бекенді кешуємо результати пошуку в Redis з TTL 5 хвилин — однакові запити з різних пристроїв повертають кеш. Без кешування кожен пошук генерує запит до GDS, який може бути платним або повільним. Redis скорочує кількість звернень в 3–5 разів, економлячи бюджет на API — до 40% витрат.
Як кешування впливає на UX? — розробка мобільного додатку
Карта готелів — через MapKit (iOS) або Google Maps SDK (Android). Кластеризація маркерів через GMSMarkerCluster / MKAnnotationView з clusteringIdentifier — без неї на Туреччині з 800 готелями карта перетворюється на кашу. Кешовані геодані прискорюють завантаження карти в 2 рази.
Бронювання та оплата
Після вибору туру — перевірка актуальності ціни (GET /tours/{id}/check) та наявності місць перед оплатою. Ціни змінюються в реальному часі; тур за 75 000 руб. може подорожчати до 80 000 через хвилину.
Оплата через ЮKassa або CloudPayments з підтримкою розстрочки (Халва, Тінькофф Розстрочка). Для дорогих турів (від 100 000 руб) розстрочка збільшує конверсію на 25% — інтеграція через POST /payments з параметром payment_method_data.type = installments. Після оплати — автоматичне відправлення ваучера та квитків у додаток.
Особистий кабінет туриста
Історія подорожей, поточні бронювання, завантаження документів. Розпізнавання паспорта через ML Kit Document Scanner (Android) або VisionKit (iOS). Нагадування через FCM/APNs: «До вильоту 3 дні — перевірте документи», «Рейс затримано на 2 години» (інтеграція з FlightAware). Офлайн-доступ до ваучерів через Core Data / Room з фоновим завантаженням PDF.
Порівняння підходів до пошуку
| Підхід | Час першого результату | Навантаження на API | Конверсія в бронь |
|---|---|---|---|
| Синхронний (очікування всіх) | 15–20 сек | Висока (завжди повний запит) | 60% відмов |
| Прогресивний (WebSocket) | 2–3 сек | Середня (частковий кеш) | 30% відмов |
| Прогресивний + кеш Redis | 1–2 сек | Низька (до 80% кеш) | 15% відмов |
Що входить в роботу
Повний чек-лист етапів
- Аналітика та UX-прототип - Проектування API-агрегатора - Інтеграція з 1–3 туроператорами - Розробка iOS (SwiftUI+Combine) та Android (Jetpack Compose) - Впровадження пошуку з прогресивним завантаженням - Кешування Redis - Платіжний модуль (ЮKassa/CloudPayments + розстрочка) - Особистий кабінет з офлайн-доступом - Push-сповіщення (APNs + FCM) - Публікація в App Store та Google Play (гарантія проходження) - 1 місяць техпідтримки та навчання персоналу| Етап | Термін | Результат |
|---|---|---|
| Аналітика та проектування | 1–2 тижні | ТЗ, UX-прототип |
| Інтеграція з туроператорами | 2–4 тижні | Робочий бекенд-агрегатор |
| Розробка мобільного додатку | 4–6 тижнів | iOS та Android клієнти |
| Тестування та деплой | 1–2 тижні | Реліз в магазинах |
Типові помилки при розробці туристичного додатку
- Прямі запити до GDS з мобільного пристрою — довго та небезпечно. Завжди використовуйте проміжний бекенд.
- Відсутність кешування — переплата за API в 3–5 разів, повільний повторний пошук.
- Ігнорування офлайн-режиму — додаток марний без інтернету (наприклад, за кордоном).
- Невраховані вимоги App Store щодо контенту (Section 4.2) — магазин може відхилити реліз.
Скільки коштує розробка мобільного додатку для турагентства
Повний цикл — від 10 до 14 тижнів на повноцінний додаток з інтеграцією 1–2 туроператорів, картою, оплатою та особистим кабінетом. Вартість розраховується індивідуально після аналізу вимог. Замовте розробку — ми гарантуємо результат і дотримання термінів. Зв'яжіться з нами для оцінки вашого проекту.
За даними Apple Developer Documentation, прогресивне завантаження покращує UX на 30%.