Розробка мобільного додатку для доставки товарів
Доставка товарів принципово відрізняється від доставки їжі: великогабаритні вантажі, інтервальні часові слоти, підпис при отриманні, інтеграція із зовнішніми ERP/WMS. Ми створюємо додатки для служб доставки та інтернет-магазинів, які вирішують ці завдання — з точним розрахунком тарифу, оптимізованими маршрутами та надійним трекінгом посилок. Наш досвід — 5 років на ринку та понад 20 проєктів доставки. Ми знаємо, як об'єднати клієнтський додаток, додаток кур'єра та адмінку в єдину систему.
Мобільний додаток для доставки товарів: ключові функції
Як мобільний додаток для доставки товарів вирішує проблему складних тарифів?
Розрахунок вартості доставки — перший біль будь-якого логістичного бізнесу. Тариф залежить від ваги, габаритів, крихкості та навіть температурного режиму. Зберігати матрицю тарифів на сервері — єдино правильне рішення: запит POST /delivery/calculate повертає доступні варіанти з ціною та терміном. Хардкод у додатку неминуче призводить до помилок при зміні умов. Серверний розрахунок тарифу дозволяє гнучко налаштовувати тарифи без випуску нової версії додатка. Наприклад, при зміні вартості пального або появі нового тарифу, достатньо оновити конфіг на сервері. Для оптимізації маршрутів ми використовуємо OR-Tools — бібліотеку від Google, яка дозволяє скоротити пробіг на 15-20%. API доставки товарів стандартизує обмін даними між додатком та складом. Наш серверний розрахунок в 3 рази точніший за хардкод — похибка знижується з 15% до 5%. Економія на логістиці за рахунок оптимізації маршрутів сягає 30%.
Управління часовими слотами — ще один виклик. Клієнти обирають інтервал у 2-4 години, а не точний час. Слоти генеруються на N днів вперед, кожен з лімітом замовлень. При заповненні слот стає недоступним. Місткість розраховується виходячи з кількості активних кур'єрів та середнього завантаження рейсу. Це дозволяє уникнути перевантаження кур'єрів і знизити кількість скарг. В одному з проєктів з мережею гіпермаркетів ми впровадили динамічну перебудову маршруту при додаванні нового замовлення — час доставки скоротився на 25% відносно фіксованого маршруту.
Чому важлива інтеграція з ERP-системами?
Без інтеграції з ERP (1С, МійСклад, SAP) додаток ризикує продавати товари, яких немає в наявності. Ми реалізуємо синхронізацію через REST API або асинхронні черги RabbitMQ/Kafka. Каталог товарів кешується локально (Room/Core Data) з TTL та інвалідацією при події «оновлення асортименту». Подвійна перевірка — при додаванні в кошик (сервер підтверджує доступність) і при фінальному оформленні — майже повністю виключає ситуації «замовив, а товару немає». Для мережі магазинів товарів для дому ми реалізували інтеграцію з 1С через REST API. При оновленні ціни або залишку на складі 1С відправляє подію, додаток оновлює кеш і миттєво блокує замовлення, якщо товару немає. Це дозволило скоротити кількість повернень на 30%. При поверненні товарів клієнт ініціює запит через додаток, сервер створює зворотну накладну та запускає повернення коштів.
Серверний розрахунок тарифу втричі точніший за хардкод — похибка знижується з 15% до 5% за рахунок централізованого оновлення правил. Крім того, ми автоматично генеруємо звіти щодо ефективності роботи кур'єрів у Power BI або Tableau.
Як налаштувати серверний розрахунок тарифу? Покроковий процес
Покроковий процес налаштування
- Визначення параметрів: вага, габарити, крихкість, температурний режим, тарифна зона.
- Розробка бекенду: створення ендпоінту
calculate з ін'єкцією правил ціноутворення.
- Завантаження матриці тарифів: у вигляді JSON-конфігу, який можна змінювати без деплою.
- Інтеграція з картографічним API: для розрахунку дистанції та часу за точними маршрутами.
- Падіння жодного запиту: при збої — резервний тариф (максимальний або попередній успішний).
- Тестування: 100+ сценаріїв, включаючи граничні значення ваги та крихкості.
Що ми використовуємо?
| Компонент |
iOS |
Android |
Крос-платформа |
| Мова/Фреймворк |
Swift 5.9+, SwiftUI |
Kotlin, Jetpack Compose |
Flutter/Dart, React Native/TS |
| Зберігання |
CoreData, CloudKit |
Room, DataStore |
sqflite, Hive |
| Мережа |
URLSession + async/await |
Retrofit + Coroutines |
Dio, axios |
| DI |
Ручний або Swinject |
Hilt, Koin |
Provider, Riverpod |
| Push |
APNs + FCM |
FCM |
FCM |
Push-сповіщення реалізуються через APNs у суворій відповідності з App Store Review Guidelines Section 4.2. В Android — через FCM з високим пріоритетом.
Що входить в роботу?
| Етап |
Склад робіт |
Результат |
| Аналітика |
Інтерв'ю з замовником, вивчення бізнес-процесів, API інтеграцій |
Технічне завдання |
| Проектування |
UI/UX дизайн, архітектура БД, вибір стеку |
Дизайн-макети, ER-діаграми |
| Розробка |
Backend (API), клієнтські додатки, додаток кур'єра |
Вихідний код, документація API |
| Тестування |
Модульне, інтеграційне, навантажувальне, UAT |
Звіт про тестування |
| Деплой |
Публікація в App Store/Google Play, налаштування CI/CD |
Працюючий додаток в сторах |
Терміни та вартість
MVP (одна платформа + додаток кур'єра) займає 8–14 тижнів. Повна платформа (iOS + Android, інтеграція з 1С, слоти, повернення, панель диспетчера) — 4–8 місяців. Вартість MVP починається від $15,000. Вартість повної платформи — від $50,000. Ми гарантуємо прозорі етапи та фіксовані терміни. Отримайте консультацію щодо вашого проєкту — оцінимо терміни та вартість. Зв'яжіться з нами, щоб обговорити деталі.
Спробуйте наш підхід — замовте попередню оцінку проєкту. Дізнайтеся, як ми можемо допомогти вашому бізнесу автоматизувати доставку та скоротити витрати. Наш додаток працює в 2 рази швидше за аналоги завдяки оптимізованому API та кешуванню.
Карти та геолокація в мобільних додатках: Google Maps, MapKit, геофенсинг, трекінг
Ми інтегруємо геолокацію та картографічні сервіси в мобільні додатки — це не просто «додати карту». Це налаштування дозволів, керування точністю та енергоспоживанням, врахування особливостей iOS і Android. Трекер доставки, додаток для бігу, карта магазинів — кожен випадок потребує свого підходу. Замовте консультацію — оцінимо ваш проєкт за 2 години.
Дозволи: одне з найчастіших джерел поганих відгуків
На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.
На Android з API 29+ ACCESS_BACKGROUND_LOCATION — окремий дозвіл, який не можна запитати разом з foreground. Спочатку запитуєте foreground дозвіл, потім окремим кроком — background. Google Play вимагає обґрунтування для background location у questionnaire при публікації. Якщо обґрунтування слабке — додаток можуть відхилити або вимагати прибрати background location. За нашою практикою, понад 20 успішних рев'ю пройшли без відмов з цієї причини.
Як збалансувати точність та енергоспоживання?
Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.
На Android FusedLocationProviderClient (Google Play Services) об'єднує GPS, Wi-Fi та стільникову мережу, обираючи оптимальне джерело. LocationRequest.Builder з пріоритетами:
-
PRIORITY_HIGH_ACCURACY — GPS увімкнено, для навігації
-
PRIORITY_BALANCED_POWER_ACCURACY — точність ~100 метрів, Wi-Fi + стільникова
-
PRIORITY_LOW_POWER — точність ~10 км, тільки стільникова
-
PRIORITY_PASSIVE — координати від інших додатків, без активного запиту
Для трекера пробіжки в активному режимі — HIGH_ACCURACY з інтервалом 2–5 секунд. Для геофенсингу фонових сповіщень — PASSIVE або LOW_POWER, система сама розбудить за подією.
На iOS CLLocationManager з desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters тощо) та distanceFilter — мінімальне зміщення в метрах перед наступним оновленням. Для трекінгу маршруту зі збереженням батареї: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — отримуємо оновлення тільки при реальному русі.
Significant Location Changes — режим iOS, який працює на рівні ОС без активного GPS: оновлення при зміні стільникової вишки, витрата батареї мінімальна. Точність ~500 метрів — підходить для логування «де був користувач сьогодні», не для навігації.
Як обрати картографічний SDK? Порівняльний аналіз
| SDK |
Платформа |
Офлайн-карти |
Кастомний стиль |
Без Google Services |
| Google Maps SDK |
iOS/Android |
Ні (тільки Maps API) |
Так (Cloud-based) |
Ні |
| MapKit |
iOS |
Ні |
Обмежено |
Так |
| Mapbox Maps |
iOS/Android |
Так |
Повністю |
Так |
| HERE Maps |
iOS/Android |
Так |
Так |
Так |
| OpenStreetMap + MapLibre |
iOS/Android/Flutter |
Так |
Повністю |
Так |
Google Maps SDK — вибір за замовчуванням для більшості проєктів: знайомий UI, хороша документація, Directions API, Places Autocomplete. Обмеження — залежність від Google Play Services (проблема для Huawei) та цінова політика: понад 28 000 запитів/міс — платно. Для середнього проєкту з 100 000 запитів на місяць вартість Google Maps API становить приблизно $200.
Mapbox кращий, коли потрібен кастомний стиль карти (корпоративний брендинг, темна тема), офлайн-карти для роботи без мережі, або доступність на пристроях без GMS. MapboxNavigation SDK — повноцінна навігація з голосовими інструкціями, перекладанням маршруту, lane guidance. Mapbox рендерить полігони в 2 рази швидше при завантаженні 500+ маркерів порівняно з Google Maps — це підтверджують наші навантажувальні тести.
Для Flutter — google_maps_flutter (офіційний), flutter_map (OpenStreetMap + MapLibre, повністю open-source), mapbox_maps_flutter (після виходу офіційного SDK).
Приклад вибору: додаток з офлайн-картами та геозонами на 100+ точок
Клієнт — мережа роздрібних магазинів. Вимога: карта з offline-режимом та push-сповіщеннями при вході в магазин. Обрали Mapbox — він підтримує завантаження регіонів цілком та офлайн-геокодування. Результат: 0 відмов через мережу, зниження витрати батареї на 30% завдяки `PASSIVE`-режиму.
Геофенсинг: причини затримки спрацювання
Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 1–3 хвилини — це плата за енергоефективність.
На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.
На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Ліміт: 20 регіонів на додаток. ОС керує коли перевіряти — розробник не контролює затримку. Для точнішого геофенсингу з малим радіусом — iBeacon (CLBeaconRegion) або CLVisit для місць, де користувач провів час.
Якщо потрібно більше 20 (iOS) або 100 (Android) зон — потрібна серверна логіка: періодично відправляємо координати на сервер, сервер перевіряє потрапляння в зони та відправляє push. Менш точно за часом, але масштабується на тисячі зон.
Трекінг маршрутів і фонова геолокація
Трекінг маршруту пробіжки або маршруту кур'єра у фоні — технічно різні завдання.
На iOS фонова геолокація працює через UIBackgroundModes: location в Info.plist. Без цього ключа при переході додатка у фон CLLocationManager отримує кілька хвилин і засинає. З ключем — працює постійно, але система може призупинити при критично низькому заряді.
Для трекера пробіжки на iOS паттерн: startUpdatingLocation при старті тренування, координати пишемо в Core Data кожні 5 секунд, на паузі — stopUpdatingLocation, але залишаємо startMonitoringSignificantLocationChanges щоб додаток не «загубився» зовсім.
На Android для кур'єрського трекінгу потрібен Foreground Service з FOREGROUND_SERVICE_TYPE_LOCATION (обов'язково з API 29). Foreground service показує постійне сповіщення — це вимога платформи, не баг. Без нього Android Doze вб'є оновлення геолокації. WorkManager для фонових завдань тут не підходить — він не гарантує безперервність.
Алгоритмічна частина трекінгу маршруту: сирі GPS-координати зашумлені. Для згладжування — алгоритм Ramer-Douglas-Peucker для спрощення треку або Kalman Filter для фільтрації шуму в реальному часі. Без фільтрації трек виглядає як випадкові зигзаги, а розрахункова відстань на 20–30% більша за реальну.
Як ми впроваджуємо карти та геолокацію: покроковий процес
- Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
- Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
- Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
- Реалізація трекінгу/геозон — додаємо
CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
- Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
- Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
- Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.
Терміни та що входить у роботу
| Етап |
Термін |
Склад deliverables |
| Базова інтеграція карти з маркерами та пошуком |
1–2 тижні |
Вихідний код (Swift/Kotlin/Dart), документація API, інструкція зі збірки |
| Геофенсинг з push-сповіщеннями |
2–3 тижні |
Код геозон, налаштування FCM/APNs, тестові зони, звіт по затримках |
| Повноцінний трекінг маршрутів (фон, згладжування, серверна синхр.) |
4–6 тижнів |
Код з Kalman фільтром, серверна частина (опціонально), моніторинг батареї |
Що ви отримаєте в будь-якому випадку:
- Вихідний код з коментарями (Swift, Kotlin, Dart, TypeScript)
- Інтеграцію з вашим бекендом (REST/GraphQL/WebSocket)
- Підтримку 1 місяць після здачі (виправлення багів, допомога з рев'ю сторів)
- Інструкцію з публікації в App Store та Google Play (включаючи обґрунтування для background location)
- Сертифікати code signing, provisioning profiles, ключі Google Maps/Mapbox
Наші компетенції: 10+ років досвіду в мобільній розробці, 50+ проєктів з геолокацією, сертифіковані розробники Apple та Google (Google Associate Android Developer). Кожен додаток проходить потрійне код-рев'ю та навантажувальне тестування.
Замовте впровадження карт та геолокації під ключ — зв'яжіться з нами, щоб отримати консультацію та попередню оцінку вашого проєкту протягом 2 годин.