Приложение для такси — одна из технически плотных задач в мобильной разработке. Здесь сходится сразу несколько систем: геолокация, real-time трекинг, матчинг водителей, расчёт стоимости, платёжный шлюз, push-уведомления и поддержка офлайн-состояния. Проблемы возникают на стыках — именно поэтому мы проектируем архитектуру системно и на старте закладываем решения, которые впоследствии экономят до трёх месяцев разработки. За 5+ лет мы реализовали более 50 проектов для такси и доставки и гарантируем передачу всей документации и исходного кода. Если вы начинаете разработку MVP, свяжитесь с нами — поможем с прототипом и оценкой.
Как работает real-time матчинг?
Матчинг — сердце системы. Когда пассажир создаёт заказ, сервер определяет ближайших свободных водителей в радиусе 1–3 км. Для этого используется Redis Geo: команда GEORADIUS drivers_online {lon} {lat} 3 km WITHCOORD WITHDIST COUNT 10 ASC возвращает список водителей за единицы миллисекунд. Затем сервер выбирает оптимального кандидата по комбинации расстояния, рейтинга и времени последнего заказа. WebSocket-событие отправляется выбранному водителю. Если он не отвечает за 15–20 секунд, заказ передаётся следующему.
Два приложения и один бэкенд
Пассажирское и водительское приложения — разные продукты с разной логикой, но общим API. Мы проектируем их как единую систему сразу, чтобы API не разрастался непредсказуемо. Минимальный состав системы:
- Приложение пассажира (iOS + Android)
- Приложение водителя (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 — результат приходит за единицы миллисекунд.
После назначения создаётся 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.
Как интегрировать платёжный шлюз?
В России популярны 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 на Android.
Push-уведомления через FCM
Firebase Cloud Messaging единый SDK для обеих платформ; APNs работает через FCM-прослойку. Типы уведомлений: входящий заказ водителю, прибытие водителя, завершение поездки, чек. Критично: уведомление о заказе должно разбудить приложение водителя в фоне. На Android — data-уведомление вызывает onMessageReceived даже в фоне. На iOS — content-available: 1 для silent push + обычный alert. Согласно App Store Review Guidelines Section 5.1.1, необходимо запросить разрешение пользователя на push-уведомления.
Что входит в итоговую поставку?
Мы передаём полный пакет документации и артефактов:
| Компонент | Состав |
|---|---|
| Архитектура | Диаграммы C4, описание API (OpenAPI/Swagger) |
| Код | Полные репозитории с историей коммитов |
| Деплой | Инструкции для развёртывания бэкенда, CI/CD |
| Доступы | Учётные записи App Store Connect, Google Play Console, Firebase |
| Обучение | Две сессии для команды заказчика |
Сроки и команда
MVP (одна платформа пассажир + водитель, базовая навигация, один платёжный шлюз) занимает 6–10 недель. Полноценное приложение (обе платформы, surge pricing, история поездок, панель администратора, аналитика) — 4–6 месяцев. Стоимость рассчитывается индивидуально после анализа требований. Закажите консультацию — мы оценим ваш проект и предложим оптимальную архитектуру.
Apple. App Store Review Guidelines. Section 5.1.1 — Privacy: Data Collection and Storage. Retrieved from developer.apple.com/app-store/review/guidelines/.