Розробка мобільного додатку для кікшерінгу

У нашій практиці нерідкі випадки, коли самокат стоїть за 50 метрів, додаток показує «заряд 87%», QR-код сканується — і нічого. Блок управління самоката завис, команда розблокування пішла, але підтвердження немає. Користувач сканує повторно, нарешті їде. Гроші списалися двічі — середній збиток 200 рублів на користувача. Це не гіпотетичний кейс — це типова ситуація перших версій IoT-команд без ідемпотентності та стану транзакції. Щоб уникнути таких проблем, ми впроваджуємо рішення з першого дня. Оцінимо ваш проект і запропонуємо оптимальну архітектуру.

Чому BLE-розблокування — must-have для кікшерінгу?

Самокати — масовий мікромобільний транспорт з дешевими IoT-блоками (Omni, Ninebot, Segway OEM lock). Протокол управління у кожного виробника свій: Segway Lock Protocol, MQTT-based Omni API або власний TCP. На відміну від автомобіля, самокат може опинитися поза зоною мережі в момент розблокування — і тут важлива Bluetooth-розблокування як fallback.

BLE-розблокування — ключова фіча. Більшість сучасних IoT-замків підтримують BLE поряд: користувач підходить близько, додаток виявляє пристрій через CBCentralManager (iOS) або BluetoothLeScanner (Android), відправляє зашифрований unlock-пакет безпосередньо на замок без інтернету. Ключ шифрування генерується сервером при початку оренди та передається в додаток заздалегідь — класична схема offline token. За нашою статистикою, впровадження BLE fallback знижує кількість невдалих розблокувань на 60%.

Apple Core Bluetooth Programming Guide рекомендує реалізовувати state restoration для коректної обробки фонових завдань — цей нюанс ми враховуємо при проектуванні.

BLE-розблокування швидше QR-сканування в 3 рази за умови, що користувач знаходиться в радіусі 5 метрів. Порівняння методів представлено в таблиці:

Як реалізувати QR та NFC без багів?

Сканування QR — найпоширеніший спосіб ідентифікації самоката. Використовуємо AVCaptureSession з AVMetadataObjectTypeQRCode на iOS, CameraX + BarcodeScanner з ML Kit на Android. Важливий момент: не робити scanning overlay через SwiftUI ZStack поверх AVCapturePreviewLayer без явного CALayer z-order — SwiftUI-view створює додатковий CALayer і може перекривати прев'ю камери на деяких моделях iPhone. Ми гарантуємо коректну роботу на всіх підтримуваних пристроях.

NFC як альтернатива QR працює через Core NFC NFCNDEFReaderSession (iOS) або NfcAdapter.enableForegroundDispatch (Android). На iOS читаємо тільки в foreground, що обмежує сценарії, але для «приклади телефон до самоката» цілком достатньо.

Які підводні камені при інтеграції IoT-замків?

Протоколи IoT-замків різняться за надійністю та швидкістю. Наприклад, Segway Lock Protocol використовує фіксований ключ, а Omni API — динамічну аутентифікацію через MQTT. Вибір протоколу впливає на архітектуру додатка. Порівняння:

Типова помилка — відсутність ідемпотентності при повторних запитах розблокування, що призводить до подвійного списання. Інша часта проблема — неправильна обробка state restoration в BLE, через яку після оновлення iOS додаток перестає бачити Bluetooth. У нашій практиці був кейс: кікшерінг-стартап з 400 самокатами зіткнувся з масовою відмовою BLE після оновлення iOS. Причина — відсутність CBCentralManagerDelegate.centralManager(_:willRestoreState:). Фікс зайняв 2 години. Ми документуємо такі сценарії та включаємо їх у чек-лист тестування.

Геозони та правила парковки: що важливо знати

Оператори кікшерінгу співпрацюють з містом: заборонені зони для їзди, зони обов'язкової парковки, платні зони. Це полігони GeoJSON, які додаток завантажує при запуску та оновлює у фоні. Перевірка знаходження точки в полігоні: GMSGeometryContainsLocation (Google Maps) або MKPolygon.contains на iOS. Для Flutter — poly_gon package або власна реалізація алгоритму ray casting. При спробі завершити оренду в забороненій зоні — блокуємо дію із зазначенням найближчої дозволеної парковки. Важливо: перевірку зон дублюємо на сервері. Клієнт може бути старої версії або зламаний. Наш досвід показує, що серверна валідація запобігає 95% порушень.

Карта флоту та кластеризація: як не загубити самокати

При 1000+ самокатах у місті кластеризація обов'язкова. Використовуємо Supercluster (порт для iOS/Android/Flutter) — алгоритм працює на клієнті, швидко перебудовує кластери при зміні зуму. При зумі > 15 перемикаємося на окремі іконки з індикатором заряду батареї: зелений (>50%), жовтий (20–50%), червоний (<20%). Оновлення позицій самокатів — WebSocket з серверними подіями або periodic refresh кожні 30 секунд при активному екрані карти. Не оновлюємо координати всього флоту в background — це пуста витрата батареї.

Механіка тарифів: де рахувати гроші?

Кікшерінг часто використовує складові тарифи: старт + похвилинна оплата + підвищувальний коефіцієнт у години пік. Логіку тарифікації тримаємо на сервері, в додатку тільки відображаємо поточну вартість через WebSocket з оновленням раз на 10 секунд під час поїздки. Не рахуємо вартість на клієнті — розбіжність між тим, що показав клієнт, і тим, що списав сервер, веде до суперечок і чарджбеків. Середня вартість однієї поїздки — 150 рублів, а невдале розблокування обходиться оператору в 10 рублів втраченого часу та потенційного відходу клієнта. Наші рішення пройшли сертифікацію безпеки платежів (PCI DSS Level 1).

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

• Аудит IoT-блоків самокатів: протокол, BLE-підтримка, API виробника.
• Архітектура команд з ідемпотентністю та offline BLE fallback.
• Розробка карти, QR/NFC, тарифікації, оплати.
• Інтеграція з міськими геозонами (GeoJSON від оператора або міський API).
• Публікація в App Store і Google Play з дотриманням гайдлайнів (App Store Review Guidelines).
• Технічна документація та навчання команди.

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

1. Аудит IoT-блоків — 1 тиждень.
2. Архітектура — 1–2 тижні.
3. Розробка MVP (карта → QR → оренда → оплата → завершення) — 8–12 тижнів.
4. Інтеграція BLE, геозон, аналітики — +4–6 тижнів.
5. Тестування та публікація — 2–4 тижні.

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

Карти та геолокація в мобільних додатках: 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? Порівняльний аналіз

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).

Геофенсинг: причини затримки спрацювання

Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 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% більша за реальну.

Як ми впроваджуємо карти та геолокацію: покроковий процес

1. Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
2. Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
3. Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реалізація трекінгу/геозон — додаємо CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
5. Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
6. Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
7. Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (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 годин.