Разработка мобильного приложения для такси
Приложение для такси — одна из технически плотных задач в мобильной разработке. Не потому что какой-то компонент сам по себе сложен, а потому что здесь сходятся сразу несколько систем: геолокация, real-time трекинг, матчинг водителей, расчёт стоимости, платёжный шлюз, push-уведомления и поддержка офлайн-состояния. Проблемы возникают на стыках.
Два приложения и один бэкенд
Пассажирское приложение и приложение водителя — разные продукты с разной логикой, но общим API. Проектировать их как единую систему сразу, не дорабатывать по ходу — иначе API будет разрастаться непредсказуемо.
Минимальный состав системы:
- Приложение пассажира (iOS + Android)
- Приложение водителя (iOS + Android)
- Бэкенд API (REST + WebSocket/MQTT)
- Панель администратора (опционально на первом этапе)
Геолокация и поиск водителей
Ключевой сценарий: пассажир открывает приложение → видит ближайших водителей на карте → назначается оптимальный → видит его движение в реальном времени.
Водители, находясь в режиме ожидания, отправляют координаты каждые 5-10 секунд. Сервер хранит актуальные позиции в Redis Geo: GEOADD drivers_online {lon} {lat} {driver_id}. Поиск ближайших: GEORADIUS drivers_online {lon} {lat} 3 km WITHCOORD WITHDIST COUNT 10 ASC — возвращает ID водителей в радиусе 3 км, отсортированных по расстоянию, за единицы миллисекунд.
После назначения водителя — WebSocket-канал между пассажиром и водителем. Промежуточный сервер пересылает координаты водителя только назначенному пассажиру. Трансляция координат всем водителей всем пассажирам — неверная архитектура.
Расчёт маршрута и стоимости
Google Directions API или OSRM (self-hosted, бесплатно) для расчёта маршрута от водителя к пассажиру и от пассажира к точке назначения. Ответ содержит distance (метры) и duration (секунды) — база для предварительного расчёта стоимости.
Формула стоимости: base_price + per_km * distance_km + per_min * duration_min. Плюс коэффициент спроса (surge pricing) — хранится на сервере, умножается при дефиците водителей. Итоговую стоимость всегда считаем на сервере, не на клиенте — клиент только показывает.
Ценообразование на маршруте. Предварительная цена vs финальная: показываем пассажиру расчётную стоимость до поездки, фиксируем финальную на основе фактического маршрута. Разницу ограничиваем ± 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 — это дороже в разработке, но пользователь не уходит из приложения.
Статусы поездки. accept → arriving → waiting → in_progress → completed. Каждый переход — явное действие водителя (кнопка), не автоматика. Автоматика только для таймаутов.
Приложение пассажира
Экран заказа. Карта с текущей позицией, поле ввода адреса назначения с автодополнением (Google Places API или DaData), выбор класса автомобиля, предварительная стоимость, кнопка «Заказать».
После заказа. Анимированный маркер водителя движется к пассажиру. Расстояние и время до прибытия обновляются в реальном времени через WebSocket. Данные водителя: имя, фото, рейтинг, марка и номер автомобиля.
Во время поездки. Маршрут на карте, текущее положение, расчётное время прибытия. Кнопка SOS → звонок в службу безопасности или экстренный контакт.
После поездки. Оценка водителя (1-5 звёзд), чаевые, чек на email/SMS.
Платёжная интеграция
В России — CloudPayments, YooKassa (ЮКасса), Tinkoff Acquiring. SDK для iOS и Android — готовые, интеграция занимает день. Важно: для сохранения карты пользователя используем токенизацию — реальный номер карты не хранится в приложении и на наших серверах, только токен.
CloudPayments iOS SDK: CPCloudPayments → CRPaymentForm.present(with:). Android: CloudPaymentsApi.doPay(context, cryptogram, saveCard).
Apple Pay / Google Pay — приоритетный способ для пользователей без сохранённой карты. PKPaymentAuthorizationViewController на iOS, PaymentsClient из Google Pay API на Android.
Push-уведомления
Firebase Cloud Messaging (FCM) — и iOS, и Android через единый SDK. APNs для iOS работает через FCM-прослойку. Типы уведомлений: входящий заказ водителю, водитель прибывает (пассажиру), поездка завершена, чек.
Критичный сценарий: уведомление о входящем заказе должно разбудить приложение водителя, если оно в фоне. На Android — data-уведомление (не notification) запускает onMessageReceived даже в фоне. На iOS — content-available: 1 для silent push + обычный alert для отображения.
Стек
| Компонент | Технологии |
|---|---|
| iOS | Swift, SwiftUI/UIKit, GoogleMaps SDK, FCM |
| Android | Kotlin, Jetpack Compose, Google Maps SDK, FCM |
| Flutter (опционально) | Dart, google_maps_flutter, firebase_messaging |
| Бэкенд | Node.js / Go / Python (FastAPI), WebSocket, Redis Geo, PostgreSQL + PostGIS |
| Платежи | CloudPayments / YooKassa + Apple Pay / Google Pay |
Сроки
Минимальный MVP (одна платформа пассажир + водитель, базовая навигация, один платёжный метод): шесть-десять недель.
Полноценное приложение (обе платформы, surge pricing, история поездок, панель администратора, аналитика): четыре-шесть месяцев.
Стоимость рассчитывается индивидуально после анализа требований и декомпозиции задач.