Як ми створюємо кур'єрські додатки, які не вбивають фонову геолокацію
Кур'єр прийняв замовлення, виїхав — і додаток упав у background-killed на Android Xiaomi з MIUI. FusedLocationProvider перестав віддавати координати, трек обірвався, диспетчер не бачить машину. Це не гіпотетичний сценарій — це стандартна проблема кур'єрських додатків на агресивних лаунчерах MIUI, OneUI, EMUI, де foreground service вбивається збирачем сміття батареї.
Наш досвід понад 5 років і понад 20 реалізованих проєктів для кур'єрських служб дозволяє гарантувати стабільну роботу навіть на проблемних пристроях. Ми розробляємо додатки під ключ — від архітектури до публікації в App Store та Google Play.
Проблема: геотрекінг на Android
На Android для безперервної геолокації потрібен Foreground Service з явним повідомленням у рядку статусу. Без нього на Xiaomi/Huawei/OPPO додаток помре через 5–10 хвилин у фоні незалежно від WakeLock. Але й foreground service не панацея: MIUI додає батарейні обмеження навіть на запущені сервіси, якщо користувач не дозволив автозапуск вручну.
Правильний підхід: при першому запуску показуємо Intent на системний екран «Автозапуск» (для MIUI — com.miui.securitycenter, для Huawei — com.huawei.systemmanager). Це не завжди красиво, але це єдиний спосіб гарантувати трекінг. Плюс — батч-відправка координат: накопичуємо точки в пам'яті, відправляємо кожні 10–15 секунд одним запитом замість 15 окремих.
На iOS проблем менше: CLLocationManager з allowsBackgroundLocationUpdates = true та pausesLocationUpdatesAutomatically = false працює надійно. Але significant-change location updates не підходять для кур'єрів — вони спрацьовують лише при зміні соти (~500 м точність), що не годиться для відображення на карті в реальному часі.
Чому варто робити два окремі додатки?
Кур'єрський сервіс — це майже завжди два окремі додатки: для кур'єра та для клієнта. Іноді додається третій — диспетчерський web-інтерфейс. Але мобільна частина може бути в одному проєкті з різними flavor/scheme:
-
Android Flavors:
courierApp/clientApp— різніapplicationId, іконки, дозволи - iOS Targets: два target'и в одному Xcode-проєкті, shared код через SPM-пакет
Це дозволяє перевикористовувати бізнес-логіку (мережевий шар, моделі даних, геолокаційний модуль) між двома додатками без дублювання коду. Порівняння підходів:
| Підхід | Дублювання коду | Складність підтримки | Час розробки MVP |
|---|---|---|---|
| Два окремі проєкти | 100% | Висока | 8–12 тижнів |
| Один проєкт з flavor/target | 10–20% | Низька | 6–10 тижнів |
Алгоритм призначення та маршрутизація
Логіка розподілу замовлень живе на сервері. Мобільний клієнт лише отримує призначення через push (FCM/APNs з priority: high) і підтверджує прийняття. Важливо: FCM high priority на Android гарантує доставку навіть в Doze mode, але лише якщо у додатка є RECEIVE_BOOT_COMPLETED і правильно налаштований FirebaseMessagingService.
Маршрут до отримувача будуємо через Google Maps Directions API або OSRM (якщо потрібен self-hosted без плати за API-виклики). Покрокову навігацію не реалізуємо в додатку — відкриваємо Google Maps / Яндекс.Навігатор через deep link, передаючи координати точки доставки.
ETA та трекінг для клієнта
Клієнт бачить кур'єра на карті — це WebSocket або Server-Sent Events від сервера до клієнтського додатка. Координати оновлюються кожні 5–10 секунд. На карті використовуємо Marker з анімацією animateCamera, щоб точка не стрибала, а плавно рухалась — ValueAnimator (Android) або CABasicAnimation (iOS).
ETA рахується на стороні сервера через Google Maps Distance Matrix API або HERE Routing API і передається клієнту. Не обчислюємо ETA на пристрої — там немає актуальних даних про затори.
Як відбувається підтвердження доставки?
Три варіанти підтвердження, які зустрічаються найчастіше:
- Фото посилки/дверей —
CameraX(Android) абоAVFoundation(iOS) + завантаження в S3/GCS - PIN-код, який знає отримувач — простий TOTP або статичний код із замовлення
- Підпис на екрані —
Canvas/UIBezierPath, зберігаємо як SVG або PNG
Код підпису робимо з strokeWidth, що залежить від швидкості руху пальця — виглядає значно природніше, ніж лінія постійної товщини.
Що входить у роботу?
- Архітектурна документація та вибір стеку
- Розробка Android (Kotlin + Jetpack Compose) та iOS (Swift + SwiftUI)
- Інтеграція з вашими OMS/WMS через REST або GraphQL
- Налаштування push-повідомлень (FCM / APNs)
- Публікація в App Store та Google Play
- Навчання персоналу (2 дні)
- Технічна підтримка 2 тижні після запуску
Етапи та терміни
Мінімальний життєздатний продукт — два додатки (кур'єр + клієнт) з геотрекінгом, призначенням замовлень та підтвердженням доставки: 6–10 тижнів при команді 2 розробники + дизайнер. Повна платформа з диспетчерським модулем, аналітикою та інтеграцією з зовнішніми OMS/WMS-системами — 4–6 місяців. Вартість розраховується індивідуально після аналізу вимог.
Ми гарантуємо стабільну роботу на пристроях Xiaomi, Huawei та Samsung. Замовте розробку під ключ — зв'яжіться з нами для безкоштовної оцінки вашого проєкту.