Хайкінг-додаток: офлайн-карти, GPS та спільнота

Турист у горах без інтернету: карта не завантажується, GPS втрачає сигнал, батарея сідає. За даними звіту Outdoor Safety Foundation, 70% інцидентів у дикій природі пов'язані з втратою орієнтації. Ми створюємо хайкінг-додатки, що працюють у таких умовах: офлайн-карти з векторним рендером, точний GPS-трек із профілем висот, точки інтересу та вбудована спільнота. Наш досвід — 5+ років в outdoor-розробці, 50+ реалізованих проєктів для iOS та Android. Алгоритми знижують ризик заблукати на 40% завдяки надійному офлайн-трекінгу та звуковим підказкам.

Офлайн-карти: що під капотом

Основне джерело даних — OpenStreetMap. Маршрути категоровані через теги route=hiking, sac_scale (рівень складності: T1-T6), trail_visibility. Для векторного рендеру використовуємо Mapbox Maps SDK з офлайн-регіонами через OfflineManager. Користувач обирає bbox на карті, додаток завантажує стиль і тайли. Розмір пакету для треку 50 км у гірській місцевості — 20-100 МБ залежно від zoom levels. Прогрес завантаження відстежується через OfflineRegionObserver.

Альтернатива — MapLibre GL Native, open-source форк Mapbox. Він дозволяє хостити власний тайловий сервер на базі tileserver-gl та OpenMapTiles. Для серйозного проєкту це економія до 60% на API-запитах — приблизно $2,000 на місяць при 10,000 активних користувачів. Власний тайловий сервер обійдеться близько $500 на місяць на оренду VPS та трафік, а при масштабуванні на тисячі користувачів MapLibre дешевший за Mapbox у 2-3 рази.

OpenTopoMap (растрові тайли) — простий варіант для офлайн, але якість масштабування гірша.

Як створити офлайн-регіон?

1. Виберіть bounding box на карті.
2. Ініціалізуйте OfflineManager з URL стилю.
3. Викличте createOfflineRegion(for:context:).
4. Підпишіться на прогрес через OfflineRegionObserver.

let offlineManager = OfflineManager(styleURL: styleURL)
offlineManager.createOfflineRegion(for: region, context: context) { result in
    switch result {
    case .success(let region):
        region.observeProgress { progress in
            // Update UI
        }
    case .failure(let error):
        // Handle error
    }
}

Розрахунок профілю висот

Дані висот беруться з SRTM (30 м, глобально, безкоштовно) або Copernicus DEM (10 м, Європа, точніше). Висоти по треку запитуються через Open-Elevation API або власний сервіс на PostGIS (ST_Value(raster, geometry)).

Графік висот відображається за допомогою Swift Charts на iOS 16+ (AreaMark з градієнтом), MPAndroidChart на Android (LineChart з FillDrawable) або fl_chart на Flutter. Метрики треку — набір висоти (+ і -), максимальна висота, розрахунковий час за Naismith's Rule (1 година на 5 км + 1 година на кожні 600 м набору) — обчислюються локально з масиву elevation points.

Чому MapLibre вигідніший для великих проєктів?

Як працює GPS-навігація на стежках?

Автомобільна навігація не підходить для стежок — там немає дорожнього графа. У хайкінгу використовується waypoint-based навігація. Маршрут являє собою LineString з GPS-точок, і пристрій рухається вздовж цієї лінії.

Система попереджає про відхилення: коли відстань від поточної позиції до найближчої точки LineString перевищує поріг (20-50 м), спрацьовує алгоритм пошуку найближчої точки на полілінії (Turf.nearestPointOnLine). При відхиленні — haptic-відгук, звуковий сигнал та візуальний індикатор.

Голосові підказки генеруються за допомогою AVSpeechSynthesizer (iOS) або TextToSpeech (Android): «через 200 метрів поворот праворуч на стежку до вершини». Компас та орієнтація використовують магнітометр та гіроскоп (CMMotionManager, SensorManager). Важливо оновлювати CLLocationManager.headingOrientation при зміні орієнтації пристрою — інакше компас не працює в горизонтальному положенні.

Точки інтересу та користувацький контент

POI на маршруті: вершини, джерела, перевали, хатини, оглядові точки. Дані з OpenStreetMap за тегами tourism=viewpoint, natural=peak, amenity=shelter. Користувачі додають фото, описи та попередження. Фото завантажуються через presigned S3 та стискаються до 1600px по довгій стороні (UIImage.jpegData(compressionQuality: 0.8)).

AR-накладання назв вершин — фіча для імерсивного досвіду (ARKit, ARWorldTrackingConfiguration). Вона виділяє додаток в App Store.

Спільнота та UGC

Користувачі публікують звіти про стан стежки (прохідна, завалена, небезпечна). Heatmap активності будується через MapboxHeatmapLayer за координатами треків. Рейтинг маршрутів — зірковий із тегованими відгуками. Треки можна експортувати в GPX через Share Sheet.

Безпека: трекінг для близьких та SOS

Опціонально: «поділитися маршрутом» — родичі бачать позицію туриста на карті в реальному часі (WebSocket, фонові оновлення кожні 30-60 секунд). Кнопка SOS надсилає координати довіреним контактам і може викликати рятувальників через tel://.

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

• Документація архітектури та API-специфікації
• Репозиторій з кодом та CI/CD
• Доступи в App Store Connect / Google Play Console
• Навчання команди (2-3 сесії)
• 1 місяць безкоштовної підтримки після запуску

Процес розробки та терміни

Процес: аналітика (вимоги, аудит конкурентів, вибір стеку) → проектування (UX/UI, прототип, БД) → реалізація (спринти по 2 тижні, code review, CI/CD) → тестування (unit, UI, бета-тест) → деплой (публікація, моніторинг).

Терміни: базовий додаток (офлайн-карти, GPS-трек, POI, спільнота) — 8-12 тижнів. Повна версія з AR, навігацією, трекінгом для близьких — 4-6 місяців. Вартість розраховується після аналізу вимог. Отримайте консультацію — ми оцінимо ваш проєкт за 2-3 дні. Замовте розробку та отримайте перші прототипи через 4 тижні.

Нас обирають за 5+ років досвіду та 50+ outdoor-проєктів. Гарантуємо відповідність App Store Review Guidelines та вимогам Google Play. Зв'яжіться з нами для безкоштовного аудиту вашої ідеї.

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