Розробка мобільного застосунку для будівельної галузі (ConTech)

Прораб фіксує дефект на об'єкті, робить фото, записує координати — а через тиждень не може прив'язати це до конкретного елемента BIM-моделі. Фотографія є, геолокація є, а проєктна документація залишається в офісі. В результаті виправлення дефекту затягується на тижні, а дані втрачаються при зміні зміни. Ми вирішуємо це завдання: розробляємо мобільні ConTech-застосунки, які пов'язують польові дані з цифровою моделлю будівлі. Цей мобільний застосунок для будівництва вирішує ключові проблеми. Наші рішення працюють під ключ — від інтеграції з Procore до офлайн-синхронізації на будмайданчику з десятками гігабайт креслень. Використовуємо нативні технології: Swift 5.9, Kotlin, Jetpack Compose. Кожен проєкт оцінюємо індивідуально: терміни та вартість розраховуються після аудиту поточних процесів. Для прикладу, MVP із зауваженнями та PDF-кресленнями займає 8–12 тижнів. Вартість базового MVP стартує від $15,000, а повної платформи — від $50,000. Впровадження такого рішення дозволяє економити до $50,000 на рік на логістиці та затримках. Зв'яжіться з нами для аудиту вашого проєкту та оцінки термінів.

Як розробити мобільний застосунок для будівельної галузі?

Мобільний застосунок для будівництва має вирішувати три ключові завдання: прив'язка польових даних до BIM-моделі, робота без інтернету та інтеграція з існуючими будівельними платформами. Розглянемо кожне.

Інтеграція BIM-моделі

BIM-модель промислового об'єкта у форматі IFC часто важить від 200 до 800 МБ. Відкрити її на iPhone в нативному viewer — завдання нетривіальне. Для цього застосовують два підходи: потоковий рендеринг з сервера та нативний viewer.

Потоковий рендеринг використовує Autodesk Forge, який перетворює IFC/RVT у SVF2-формат. Мобільний клієнт отримує лише видимі об'єкти через WebGL viewer. Працює на будь-якому пристрої, але потребує інтернет та платний API. Нативний viewer конвертує IFC у glTF через IfcOpenShell, нарізає на LOD-рівні: груба геометрія для далекого виду, детальна для наближення. Рендеринг через SceneKit (iOS) або Filament (Android). Споживання пам'яті керується через streaming geometry — завантажуються лише блоки в поточному frustum. Нативний viewer критичний для офлайн-сценаріїв: він економить до 70% трафіку при щоденному використанні та в 2-3 рази швидше за потоковий при роботі офлайн. Нативний viewer забезпечує в 3 рази швидше завантаження сцен порівняно з потоковим при офлайн-режимі. Потоковий рендеринг vs нативний viewer — це вибір між швидким впровадженням і максимальною автономністю.

Чи варто інвестувати в нативний BIM viewer? {#h-question-1}

Так, якщо ваші об'єкти часто знаходяться поза зоною стабільного інтернету. Використання мобільного BIM viewer дозволяє інженерам переглядати модель прямо на об'єкті без затримок. Нативний viewer окупається за рахунок економії трафіку та часу.

Офлайн-синхронізація

Чому офлайн-синхронізація критична? Будмайданчик часто знаходиться в зоні слабкого покриття. Зауваження, зроблене в підвалі об'єкта, має бути збережене локально та синхронізоване при появі мережі. Використовуємо Room + WorkManager (Android) або CoreData + BGAppRefreshTask (iOS). Пріоритетна черга: спочатку синхронізація фото та координат, потім оновлення статусів. Це знижує час доставки дефекту до проєктувальника з 3 днів до 4 годин.

Прив'язка зауважень до BIM-елемента

Прив'язка дефекту до елемента: користувач тапає на об'єкт у viewer, отримує guid IFC-елемента, до якого кріпимо зауваження. На сервері — PostgreSQL з ltree для зберігання ієрархії BIM-об'єктів. За рахунок цього пошук потрібного елемента прискорюється на 60%.

Польовий контроль та керування зауваженнями на будівництві

Кожне зауваження містить: фото дефекту (CameraX / AVFoundation, EXIF GPS), геолокація, тип дефекту з класифікатора, відповідальний підрядник, термін усунення, статус (open → in_review → resolved → closed). Середній час закриття дефекту скорочується з 5 до 2 днів.

Інтеграція з будівельними платформами: PlanGrid (Autodesk), Procore (REST API + OAuth 2.0), Buildertrend, BIM 360. Якщо у клієнта є ліцензія — інтегруємося, не дублюємо.

Геопозиціонування на будмайданчику

GPS всередині будівлі, що будується, дає ±15–50 метрів — цього недостатньо. Для точної прив'язки використовуємо: Indoor BLE (iBeacon, ~3–5 м), UWB (Apple U1, сантиметрова точність, але потребує інфраструктури), QR-коди на конструкціях (дешево, надійно, без інфраструктури). Для більшості проєктів достатньо QR-кодів на поверхах + GPS зовні.

Будівельні креслення та розмітка: PDF креслення в застосунку

Перегляд PDF-креслень з пін-зауваженнями. PDFKit (iOS), PdfRenderer (Android). На великих кресленнях (формат A0) продуктивність падає — використовуємо tile-based пагінацію. Анотації зберігаємо окремо від вихідного PDF (overlay pattern).

Облік робочого часу будівельників

Робітники відмічаються через QR на об'єкті або GPS-геозону. Фотоверифікація особи через liveness detection (Onfido або TFLite-модель).

Технологічний стек для ConTech застосунків (ConTech розробка)

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

• Аудит поточних інструментів клієнта (Procore, Autodesk, 1С)
• Вибір стратегії offline та формату даних
• Розробка та інтеграція з зовнішніми системами
• Проведення пілоту на одному об'єкті (3–4 тижні)
• Документація API та схеми даних
• Навчання команди роботі з застосунком
• 3 місяці підтримки після релізу, гарантія 12 місяців

Наші метрики

Більше 5 років досвіду в ConTech, 20+ реалізованих проєктів, 10+ інтеграцій з будівельними платформами. Сертифіковані розробники Swift та Kotlin.

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

1. Аудит: аналіз використовуваних платформ та форматів BIM.
2. Проєктування: вибір стратегії offline, дизайн екранів.
3. Розробка: реалізація функціоналу зауважень, BIM-viewer, інтеграцій.
4. Пілот: розгортання на одному об'єкті, збір зворотного зв'язку.
5. Тиражування: запуск на всіх об'єктах.

MVP (зауваження, фото, PDF-креслення): 8–12 тижнів. Повна ConTech-платформа з BIM, геопозиціонуванням та інтеграцією з ERP будівництва: 5–8 місяців. Вартість розраховується після аудиту вимог.

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

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