Розробка мобільного додатку для служби таксі (пасажир)

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

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Розробка мобільного додатку для служби таксі (пасажир)

Карти та геолокація в мобільних додаткахСкладнийвід 1 тижня до 3 місяців
Часті запитання

Розробка мобільного додатку для служби таксі (пасажир)

Поле введення адреси — найчастіше використовуване в додатку. Якщо автодоповнення працює повільніше 150 мс, користувач іде. Real-time карта з рухомими машинами — ще одна больова точка: смикані іконки викликають негативні відгуки. Платежі — третій камінь спотикання: нечитабельні помилки або довга обробка списують лояльність. На кожному проєкті ми стикаємося з цими вузькими місцями і знаємо, як їх обійти. Ми накопичили досвід на 30+ проєктах і знаємо, як уникнути цих проблем.

Як забезпечити автодоповнення адреси за 150 мс?

Google Places Autocomplete API дає якісні результати, але при великому обсязі запитів дорого. Mapbox Search API у 2-3 рази дешевший при порівнянній якості. Для СНД ефективний 2GIS Suggest API. Використовуйте sessionToken у Google Places API: один токен об'єднує серію автодоповнень + один Place Details запит в одну billing session. Без токена кожен символ — окремий запит за повною ціною. Економія може сягати $500 на місяць при 10 000 поїздок на день. Альтернатива — Mapbox, який знижує витрати на 60-70%.

API Швидкість Вартість на 10 000 запитів Регіон
Google Places Autocomplete 150-200 мс ~$2.83 (без sessionToken) Весь світ
Mapbox Search API 100-150 мс ~$1.00 (з пакетом) Весь світ
2GIS Suggest API 100-200 мс Безкоштовно до 100 000 запитів/день СНД

Визначення поточного місцезнаходження як точки посадки: CLLocationManager / FusedLocationProviderClient з одноразовим запитом (requestLocation() на iOS), потім reverse geocoding для отримання читабельної адреси. Точність важлива: якщо reverse geocoding повертає «вулиця N» замість «вулиця N, 15» — користувач не зрозуміє, куди приїде машина.

Чому інтерполяція машин критична для UX?

Real-time рух машин на карті — це анімація маркерів за отриманими координатами. Наївна реалізація: отримав нову координату → переставив маркер. Результат — смикані іконки машин.

Правильна реалізація — інтерполяція між точками. На iOS: CADisplayLink з розрахунком проміжних позицій, GMSMarker.position змінюється плавно через CABasicAnimation. На Android: ValueAnimator з LatLngInterpolator — анімуємо LatLng маркера між попередньою та новою позицією за час, що дорівнює інтервалу оновлення (зазвичай 3-5 секунд). Іконка машини має також повертатися за напрямком руху: кут обчислюється через Math.atan2 за двома послідовними точками.

WebSocket або MQTT — для отримання координат водіїв у реальному часі. При переході у фон iOS відключає WebSocket. Коли користувач повертається в додаток — потрібен reconnect та запит актуального положення через REST, інакше маркер водія залишається на старому місці. Досвід показує, що без інтерполяції кількість скарг на «застиглі» машини зростає в 4 рази.

Як вирішити проблему затримки сповіщень?

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 подію. Це знижує відсоток запізнень на 30%.

Канал сповіщення Затримка (типова) Залежність від режимів енергозбереження
APNs High-Priority 1-3 секунди Низька
FCM High-Priority 1-5 секунд Середня (Doze)
In-app WebSocket < 1 секунда Відсутня (тільки в фореграунді)

Оплата без головного болю

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 — його потрібно мапити в людиночитабельні повідомлення всіма мовами додатку. Ми гарантуємо, що користувач не побачить технічного коду помилки.

Етапи та терміни

  1. Аудит вимог — 1-2 дні
  2. Проектування флоу пасажира — 3-5 днів
  3. Інтеграція карт і геокодування — 5-7 днів
  4. Real-time трекінг — 7-10 днів
  5. Платіжний модуль — 3-5 днів
  6. Push-сповіщення — 2-3 дні
  7. Тестування (включаючи edge-cases) — 5-7 днів
  8. Публікація в App Store і Google Play — 3-5 днів

Термін: від 8 до 14 тижнів. Вартість розраховується індивідуально після аналізу вимог.

Що входить у роботу?

  • Вихідний код додатку на Swift/Kotlin/Flutter з повним стрікт-режимом
  • Документація по API інтеграцій (карти, платежі, сповіщення)
  • Інструкція з розгортання та публікації в сторах
  • Консультація щодо проходження App Store Review Guidelines та Google Play Policy
  • Гарантійна підтримка 30 днів після запуску (виправлення багів, консультації)

Отримайте консультацію — зв'яжіться з нами для обговорення вашого проєкту. Замовте розробку мобільного додатку таксі вже сьогодні.

Наші компетенції:

Останні роботи

  • Розробка мобільного додатка для компанії FEEDME
    Розробка мобільного додатка для компанії FEEDME
    1010
  • Розробка мобільного додатку для компанії XOOMER
    Розробка мобільного додатку для компанії XOOMER
    903
  • Розробка мобільного додатку для компанії RHL
    Розробка мобільного додатку для компанії RHL
    1332
  • Розробка мобільного додатку для компанії ZIPPY
    Розробка мобільного додатку для компанії ZIPPY
    1180
  • Розробка мобільного додатку для компанії Affhome
    Розробка мобільного додатку для компанії Affhome
    1107
  • Розробка мобільного додатку для компанії FLAVORS
    Розробка мобільного додатку для компанії FLAVORS
    714