Разработка мобільного додатку для служби таксі (пасажир)
Пасажирське додаток такси — інтерфейс, з яким взаємодіє кінцевий користувач. Поганий UX тут убиває конверсію, технічні помилки стають відзивами 1★ в App Store. Основна складність — real-time карта з рухомими об'єктами, точний вибір адреси та надійна оплата.
Ввід адреси та геокодинг
Поле вводу адреси — найчастіше використовується в додатку. Автодоповнення повинно працювати з латентністю до 150-200 мс, інакше користувач йде до третього символу. Google Places Autocomplete API дає якісні результати, але дорого при великих обсягах. Альтернативи: Mapbox Search API, Nominatim (OpenStreetMap, безплатно але повільніше), 2GIS Suggest API для СНГ.
Важливий нюанс: sessionToken у Google Places API. Один токен об'єднує серію автодоповнень + один Place Details запит у одну billing session. Без токена кожен символ — окремий запит за повною ціною. Реалізація без sessionToken при 10 000 поїздок на день дає в 5-10 разів більший рахунок.
Визначення поточного розташування як точки посадки: CLLocationManager / FusedLocationProviderClient з однократним запитом (requestLocation() на iOS), потім reverse geocoding для отримання читаного адреси. Точність важлива: якщо reverse geocoding повертає «вулиця N» замість «вулиця N, 15» — користувач не розуміє, куди прибуде машина.
Карта з відображенням водіїв
Real-time рух машин на карті — це анімація маркерів за отримуваними координатами. Наївна реалізація: отримав нову координату → переставив маркер. Результат — дергаючись іконки машин.
Правильна реалізація — інтерполяція між точками. На iOS: CADisplayLink з розрахунком проміжних позицій, GMSMarker.position міняється плавно через CABasicAnimation. На Android: ValueAnimator з LatLngInterpolator — анімуємо LatLng маркера між попередньою та новою позицією за час, рівний інтервалу оновлення (звичайно 3-5 секунд). Іконка машини повинна також поворотитися за напрямком руху: кут вичисляется через Math.atan2 по двом послідовним точкам.
WebSocket або MQTT — для отримання координат водіїв у реальному часі. При переході в фон iOS вимикає WebSocket. Коли користувач повертається до додатку — потрібен reconnect та запит актуального положення через REST, інакше маркер водія залишається на старому місці.
Оплата
Stripe SDK (iOS, Android) — стандарт для міжнародних проектів. PaymentSheet — готовий UI з підтримкою Apple Pay, Google Pay, карт. Інтеграція займає 1-2 дні. Для РФ/СНГ — ЮKassa (Яндекс.Касса) або CloudPayments SDK.
Apple Pay потребує окремого entitlement (com.apple.developer.in-app-payments) та зареєстрованого merchant ID у Apple Developer Portal. Google Pay — декларація в AndroidManifest.xml та прохождення production access review від Google.
Ошибка при оплаті повинна давати зрозумілий текст, а не код card_declined_insufficient_funds. Stripe повертає decline_code — його потрібно маппить у людськочитаємі повідомлення на всіх мовах додатку.
Уведомлення по статусам поїздки
Push-уведомлення: водій прийняв → водій їде → водій прибув → поїздка почалася → поїздка завершена. Кожен стан — свій текст та звук. На iOS custom звукові файли додаються в bundle та вказуються у APNs payload aps.sound. На Android — NotificationChannel з настройкою звуку через AudioAttributes.
Уведомлення «водій прибув» особливо критично — користувач повинен вийти за 2-3 хвилини. Якщо push затримався з-за Doze mode — користувач опоздає, водій уїде, буде поганий відзив. Для цього уведомлення варто використовувати high-priority push (APNs apns-priority: 10, FCM priority: high) та дублювати через in-app WebSocket событие.
Етапи та графік
Аудит вимог → проектування флоу пасажира → інтеграція карт та геокодинга → real-time трекінг → платіжний модуль → push-уведомлення → тестування (включаючи edge-cases: немає геолокації, немає інтернету, оплата відхилена) → публікація в App Store та Google Play.
Графік: від 8 до 14 тижнів. Вартість розраховується індивідуально після аналізу вимог.