Разработка мобильного приложения для службы такси (пассажир)
Пассажирское приложение такси — интерфейс, с которым взаимодействует конечный пользователь. Именно здесь плохой 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 дня. Для РФ/СНГ — ЮКасса (Яндекс.Касса) или CloudPayments SDK.
Apple Pay требует отдельного entitlement (com.apple.developer.in-app-payments) и registered merchant ID в Apple Developer Portal. Google Pay — декларация в AndroidManifest.xml и прохождение production access review от Google.
Ошибка при оплате должна давать понятный текст, а не код card_declined_insufficient_funds. Stripe возвращает decline_code — его нужно маппить в человекочитаемые сообщения на всех языках приложения.
Уведомления по статусам поездки
Push-уведомления: водитель принял → водитель едет → водитель прибыл → поездка началась → поездка завершена. Каждое состояние — свой текст и звук. На iOS sound custom files добавляются в 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 недель. Стоимость рассчитывается индивидуально после анализа требований.