Мобільний додаток таксі: геолокація, платежі, матчинг під ключ

Додаток для таксі — одна з технічно насичених задач у мобільній розробці. Тут сходиться одразу кілька систем: геолокація, real-time трекінг, матчинг водіїв, розрахунок вартості, платіжний шлюз, push-сповіщення та підтримка офлайн-стану. Проблеми виникають на стиках — саме тому ми проєктуємо архітектуру системно і на старті закладаємо рішення, які згодом економлять до трьох місяців розробки. За 5+ років ми реалізували понад 50 проєктів для таксі та доставки і гарантуємо передачу всієї документації та вихідного коду. Якщо ви починаєте розробку MVP, зв'яжіться з нами — допоможемо з прототипом та оцінкою. Вартість MVP стартує від $25,000, залежно від функціоналу.

Як працює real-time матчинг?

Матчинг — серце системи. Етапи матчингу:

1. Пасажир створює замовлення через додаток замовлення таксі додаток.
2. Сервер визначає найближчих вільних водіїв у радіусі 1–3 км. Для цього використовується Redis Geo, який у 10 разів швидший за традиційні SQL-запити для геопросторових даних: команда GEORADIUS drivers_online {lon} {lat} 3 km WITHCOORD WITHDIST COUNT 10 ASC повертає список водіїв за 1-2 мілісекунди.
3. Сервер обирає оптимального кандидата за комбінацією відстані, рейтингу та часу останнього замовлення.
4. WebSocket-подія надсилається обраному водієві. WebSocket забезпечує доставку сповіщення у 5 разів швидше, ніж push через FCM.
5. Якщо водій не відповідає за 15–20 секунд, замовлення передається наступному.

Два додатки та один бекенд

Пасажирський та водійський додатки — різні продукти з різною логікою, але спільним API. Ми проєктуємо їх як єдину систему одразу, щоб API не розростався непередбачувано. Мінімальний склад системи:

• Додаток пасажира (iOS + Android, можливо Flutter)
• Додаток водія (iOS + Android)
• Бекенд API (REST + WebSocket/MQTT)
• Панель адміністратора (опціонально на першому етапі)

Такий набір дозволяє запустити MVP, що покриває 80% функціональності.

Геолокація та пошук водіїв (додаток для водіїв таксі)

Ключовий сценарій: пасажир бачить найближчих водіїв на карті, потім призначається оптимальний водій і його маркер рухається в реальному часі. Водії в режимі очікування надсилають координати кожні 5–10 секунд. Сервер зберігає актуальні позиції в Redis Geo: GEOADD drivers_online {lon} {lat} {driver_id}. Пошук найближчих водіїв виконується командою GEORADIUS drivers_online {lon} {lat} 3 km WITHCOORD WITHDIST COUNT 10 ASC — результат приходить за 1-2 мілісекунди.

Після призначення створюється WebSocket-канал, через який сервер пересилає координати водія лише призначеному пасажиру. Транслювати координати всіх водіїв усім пасажирам — помилка, що веде до надмірного навантаження.

Розрахунок маршруту та вартості

Використовуємо Google Directions API або self-hosted OSRM — обидва повертають distance та duration, які лягають у формулу вартості: base_price + per_km * distance_km + per_min * duration_min. Коефіцієнт попиту (surge pricing) зберігається на сервері та множиться при дефіциті водіїв. Підсумкова вартість завжди розраховується на сервері — клієнт лише відображає. Різниця між попередньою та фінальною ціною обмежена ±15–20%, щоб уникнути несподіваних списань.

Додаток водія

Режим онлайн/офлайн

При переході в онлайн запускається Foreground Service (Android) або background location (iOS), координати надсилаються. Водій з'являється в Redis Geo. При офлайн — сервіс зупиняється, водій зникає з пулу.

Вхідне замовлення

Push-сповіщення та WebSocket-подія надсилаються одночасно; при активному WebSocket він пріоритетніший — швидше. Звуковий сигнал, вібрація, таймер 15–20 секунд. Без відповіді — замовлення передається наступному водієві.

Навігація та статуси

Після прийняття — маршрут з покроковими інструкціями. Використовуємо нативну навігацію (MKMapItem.openMaps() на iOS або Intent(ACTION_VIEW, Uri.parse("google.navigation:q=...")) на Android) або вбудовуємо Mapbox Navigation SDK для єдиного UX. Статуси поїздки: accept → arriving → waiting → in_progress → completed. Кожен перехід — явна дія водія, автоматика лише для таймаутів.

Додаток пасажира

На екрані замовлення — карта з поточною позицією, поле введення адреси з автодоповненням (Google Places API або DaData), вибір класу авто, попередня вартість, кнопка «Замовити». Після замовлення — анімований маркер водія, оновлення часу прибуття через WebSocket. Дані водія: ім'я, фото, рейтинг, марка та номер авто. Під час поїздки — маршрут на карті, кнопка SOS (дзвінок у службу безпеки). Після — оцінка (1–5 зірок), чайові, чек на email/SMS.

Інтеграція платіжного шлюзу

Push-сповіщення через FCM

Firebase Cloud Messaging — єдиний SDK для обох платформ; APNs працює через FCM-прошарок. Типи сповіщень: вхідне замовлення водію, прибуття водія, завершення поїздки, чек. Критично: сповіщення про замовлення повинно розбудити додаток водія у фоні. На Android — data-сповіщення викликає onMessageReceived навіть у фоні. На iOS — content-available: 1 для silent push + звичайний alert. Згідно з Apple App Store Review Guidelines, Section 5.1.1, необхідно запитати дозвіл користувача на push-сповіщення.

Що входить у роботу (deliverables)

Ми передаємо повний пакет документації та артефактів:

Наші показники (компанія)

• 5+ років досвіду у розробці додатків для таксі та доставки.
• 50+ реалізованих проєктів — від MVP до масштабованих рішень.
• 100% передача документації та вихідного коду.

Скільки часу займає розробка?

MVP (одна платформа пасажир + водій, базова навігація, один платіжний шлюз) займає 6–10 тижнів. Повноцінний додаток (обидві платформи, surge pricing, історія поїздок, панель адміністратора, аналітика) — 4–6 місяців. Вартість MVP стартує від $25,000, повноцінного рішення — від $60,000. Вартість розраховується індивідуально після аналізу вимог. Замовте консультацію — ми оцінимо ваш проєкт і запропонуємо оптимальну архітектуру.