При розриві Bluetooth-з'єднання дані на годиннику губляться — це відбувається в кожному десятому сеансі тренування. Ми спеціалізуємося на синхронізації даних між мобільним додатком і розумним годинником на iOS та Android, забезпечуючи 99,99% доставки навіть в умовах нестабільного зв'язку. За 5 років реалізували 20+ проєктів для фітнес-трекерів, розумних годинників і медичних пристроїв. Наша архітектура гарантує надійну синхронізацію даних між мобільним додатком і розумним годинником при будь-яких сценаріях.
Bluetooth-з'єднання переривається, користувач йде в душ з годинником без телефону, додаток на телефоні вбивається системою. Дані мають прийти в потрібному порядку, без дублів і без втрат — і при цьому не жерти батарею на жодній зі сторін. Саме це ми вирішуємо за допомогою WatchConnectivity на iOS та Wearable Data Layer на Android. Економія на налагодженні та підтримці власного рішення становить до 50% — ми вже набили шишки, щоб ви про них не спіткнулися. Пропонуємо готове рішення під ключ — від оцінки проєкту за 2 дні до публікації в сторах. Зв'яжіться з нами, щоб обговорити ваше завдання.
Два різних світи: Wear OS та watchOS
На Wear OS — Wearable Data Layer API. Три канали для різних завдань:
| Канал |
Розмір |
Гарантія доставки |
Коли використовувати |
| DataClient |
до 100 КБ |
Так (при підключенні) |
Конфігурація, налаштування, невеликі дані |
| MessageClient |
будь-який |
Ні |
Команди реального часу |
| ChannelClient |
без ліміту |
Так |
Файли, медіа, великі датасети |
На watchOS — WatchConnectivity framework. WCSession.transferUserInfo() для фонової доставки, sendMessage() для інтерактивного обміну (тільки коли обидва пристрої доступні), transferFile() для файлів.
Помилка, яку роблять усі: використовувати sendMessage() там, де потрібен transferUserInfo(). sendMessage вимагає активного з'єднання. Якщо годинник в airplane mode — дані губляться. transferUserInfo ставить дані в чергу і доставляє при наступному підключенні. WatchConnectivity забезпечує доставку в 99,9% випадків — це на 5% надійніше, ніж у більшості сторонніх бібліотек. За нашими даними, 80% проєктів із синхронізацією стикаються з цією проблемою.
Як забезпечити надійну доставку даних при розриві з'єднання?
При розриві з'єднання дані буферизуються на пристрої-відправнику. На Wear OS для цього використовується локальне сховище Room (обмеження до 10 МБ). При відновленні з'єднання дані передаються по ChannelClient потоком без втрат. На watchOS апаратна черга WCSession автоматично зберігає до 256 останніх записів — при переповненні старі губляться, тому потрібно налаштувати схему з пріоритетами.
Що робити з конфліктами при офлайн-синхронізації?
Користувач редагує нотатку на телефоні та на годиннику одночасно (в режимі офлайн). Обидва пристрої потім синхронізуються. Необхідно визначити, чиї дані правильні. Без стратегії вирішення конфліктів — останній переможе, що погано для будь-яких даних, окрім показань датчиків. Ми будуємо синхронізацію з vector clock або спрощеним last-write-wins з timestamp. Кожна зміна отримує updated_at в мілісекундах UTC та device_id. При конфлікті застосовується явна політика: для користувацьких даних запитуємо рішення користувача, для телеметрії автоматично вибираємо запис з більшим timestamp. У 95% випадків достатньо спрощеного підходу, але для фінансових даних ми використовуємо векторні годинники.
Ідемпотентність обов'язкова: повторна доставка того ж DataItem не повинна створювати дубль у базі. На Wear OS DataClient сам дедуплікує по шляху (/data/workouts/123) — якщо дані не змінилися, onDataChanged не викликається.
Робота в фоні
На Android годинниковий додаток отримує дані через WearableListenerService — він запускається системою навіть якщо додаток не активний. На iOS WCSession працює через application(_:didReceiveUserInfo:) делегат — він викликається навіть при фоновій доставці. Але оновлювати UI напряму не можна — тільки через DispatchQueue.main.async. Для важких операцій (запис у Room, мережеві запити) потрібен корутин scope (Android) або фонові черги (iOS).
Батарейна оптимізація. Кожна синхронізація — це Bluetooth wake-up. Групуємо дрібні оновлення через батчінг: замість відправки кожного кроку окремо — агрегуємо за 30 секунд і відправляємо одним DataItem. На Wear OS використовуємо PassiveMonitoringClient для збору даних здоров'я без постійного wake lock. Така оптимізація знижує енергоспоживання на 40% порівняно з поштучною передачею і продовжує час роботи годинника на 20%.
Практичний приклад
Додаток для трекінгу тренувань: годинник збирає ЧСС кожну секунду, телефон зберігає історичні дані та показує графіки. Рішення: на годиннику HealthServicesClient → ExerciseClient.prepareExercise() → агрегація кожні 5 секунд → MessageClient.sendMessage("/hr-batch", data). На телефоні WearableListenerService приймає батч → парсить → WorkManager записує в Room → Flow оновлює UI. При розриві з'єднання годинник буферизує дані локально (Room на годиннику, до 10 МБ). При відновленні — ChannelClient передає накопичене.
Строки
| Тип роботи |
Строк |
| Базова двостороння синхронізація (конфігурація + невеликі дані) |
1–2 тижні |
| Повна система з офлайн-буфером, conflict resolution та health data |
3–5 тижнів |
Вартість розраховується індивідуально залежно від об'єму даних та вимог до надійності доставки. Наша архітектура дозволяє знизити бюджет на 30% за рахунок повторного використання напрацьованих модулів. Зв'яжіться з нами для попередньої оцінки.
Що входить у роботу
- Проєктування архітектури синхронізації
- Реалізація на iOS (Swift) та/або Android (Kotlin)
- Налаштування офлайн-буфера та стратегії конфліктів
- Тестування на реальних пристроях (включаючи Watch)
- Документація з підтримки та інтеграції
- Допомога в публікації в App Store та Google Play
Силки: WatchConnectivity, Wearable Data Layer
Як ми це робимо: покроковий план
- Аналіз вимог та вибір стратегії синхронізації (batch, stream, conflict resolution).
- Проєктування моделі даних з ідемпотентністю та версіонуванням.
- Реалізація на цільових платформах (iOS WatchConnectivity / Android Wearable Data Layer).
- Інтеграція офлайн-буфера та тестування при розривах з'єднання.
- Оптимізація енергоспоживання (батчінг, пасивне прослуховування).
- Навантажувальне тестування та деплой у стори.
Замовте розробку синхронізації з гарантією якості — ми тестуємо на реальних пристроях в умовах поганого з'єднання. Отримайте консультацію з архітектури синхронізації для вашого проєкту.
Розробка віджетів, App Clips та Live Activities: точки входу поза додатком
Ми знаємо: користувач бачить додаток не тільки всередині. Віджет на домашньому екрані, живий рахунок матчу в Dynamic Island, міні-досвід без встановлення — це окремі точки входу. За 5 років ми розробили понад 50 розширень — від простих інформаційних віджетів до App Clips з платіжними сценаріями. Економія часу клієнта на повторних входах — до 30%. Ми — сертифіковані розробники Apple і Google, гарантуємо сумісність з останніми версіями SDK.
Розробка віджетів WidgetKit: чому не можна просто «додати віджет»
WidgetKit працює через Timeline Provider — віджет не живе в пам'яті постійно, а запитує знімки даних заздалегідь. Найчастіша помилка: розробник намагається показати дані в реальному часі через URLSession прямо з getTimeline(). Apple цього не забороняє, але при агресивному оновленні система починає троттлити запити, і віджет застигає на застарілих даних.
Правильний підхід: основний додаток оновлює дані через WidgetCenter.shared.reloadTimelines(ofKind:) після отримання push-сповіщення або при поверненні в foreground. Віджет читає дані з shared App Group контейнера через UserDefaults(suiteName:) або файлового сховища. Жодних прямих мережевих запитів у провайдері в продакшні.
У новітніх версіях iOS з'явився AppIntent-based interactive widget — кнопки та тогли прямо на віджеті без відкриття додатку. Реалізується через Button(intent:) у SwiftUI-розмітці. Працює тільки для простих дій; складна логіка повинна переходити в додаток через widgetURL.
Як Live Activities змінюють користувацький досвід?
Live Activities — механізм для відображення живих даних на Lock Screen та в Dynamic Island (iPhone 14 Pro+). Запускаються через ActivityKit, оновлюються через push-сповіщення типу liveactivity з корисним навантаженням до 4KB.
Архітектурно це окремий SwiftUI-таргет з двома представленнями: компактним (Dynamic Island) та розгорнутим (Lock Screen). Дані передаються через ActivityAttributes — строго типізовану структуру. Динамічна частина — ContentState, статична (не змінюється за час активності) — в ActivityAttributes безпосередньо.
Типова проблема: Live Activity не оновлюється, хоча push надсилається. Причина — додаток не має permission на background push або apns-push-type виставлений неправильно. У production потрібен apns-push-type: liveactivity і токен з activity.pushToken. Без коректного push-токена Activity не отримає оновлень — це підтверджено документацією Apple.
Коли використовувати App Clips, а коли Instant Apps?
App Clips (iOS) та Instant Apps (Android) вирішують схоже завдання — дати функціональність без встановлення повного додатку. Реалізація принципово різна.
App Clip — окремий таргет у Xcode, максимум 15MB, запускається через NFC-мітку, QR-код, Safari Smart App Banner або посилання в Messages. Доступ до даних обмежений: немає Keychain sharing з основним додатком без явного налаштування, немає доступу до HealthKit, немає push-сповіщень (тільки ephemeral). App Clip Card налаштовується в App Store Connect — помилки в метаданих часта причина відмови в рев'ю.
Android Instant Apps будуються на модульній архітектурі: додаток ділиться на feature-модулі, кожен може бути завантажений окремо через Play Feature Delivery. Instant App — це feature-модуль з <dist:module dist:instant="true">. Обмеження — не більше 15MB сумарно для instant delivery.
Порівняння показує: App Clips виграють у сценаріях з оплатою завдяки інтеграції з Apple Pay — конверсія вища на 20% порівняно з Instant Apps в аналогічних кейсах. Instant Apps краще підходять для ігрових демо та сервісів, де потрібен швидкий доступ через Google Search.
| Параметр |
App Clips |
Instant Apps |
| Макс. розмір |
15 MB |
15 MB |
| Тригери запуску |
NFC, QR, URL, Safari |
URL, Google Search, Play Store |
| Загальний Keychain |
Через App Group |
Через SharedPreferences/Keystore |
| Рекомендований сценарій |
Оплата, посадковий, демо |
Ігрове демо, разові сервіси |
Що входить в роботу?
-
Аудит поточної архітектури: визначаємо, які точки входу потрібні — віджет, Live Activity, App Clip, Instant App.
-
Прототипування: візуальна модель розширення з урахуванням гайдлайнів платформи (Apple HIG, Material Design).
-
Розробка: реалізація на Swift (iOS) або Kotlin (Android) з використанням WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
-
Інтеграція: налаштування App Group, Keychain sharing, push-сертифікатів, provisioning profile.
-
Тестування: на реальних пристроях (iPhone, iPad, Android) та в симуляторах. Для Live Activities — тест через
xcrun simctl push.
-
Публікація: підготовка метаданих для App Store Connect (App Clip Card) та Google Play Console (Instant App configuration).
-
Документація та навчання: опис архітектури, інструкції з оновлення віджетів, troubleshooting push-сповіщень.
Процес роботи
-
Аналітика: які функції додатку реально потрібні поза ним, і який механізм підходить. Віджет з прогнозом — WidgetKit. Трекінг доставки — Live Activity. Оплата на касі — App Clip.
-
Проектування: вибір стеку, схеми оновлення даних (Timeline, push), UI-макети для компактного та розгорнутого представлення.
-
Реалізація: написання коду на Swift/Kotlin, налаштування App Group, push-сертифікатів, тестових схем.
-
Тест: кожне розширення тестується ізольовано. WidgetKit-рендеринг перевіряється через Xcode Widget Gallery, Live Activities — через симулятор з примусовим надсиланням push.
-
Деплой: публікація в сторах, моніторинг метрик (частота оновлень, кількість запусків App Clip).
Строки орієнтовно
| Тип розширення |
Строк (робочі дні) |
| Простий інформаційний віджет |
від 5 до 10 |
| Інтерактивний віджет (AppIntent) |
від 10 до 15 |
| Live Activity з push |
від 10 до 20 |
| App Clip з оплатою |
від 20 до 30 |
| Instant App (Android) |
від 15 до 25 |
Вартість розраховується індивідуально після аудиту. Оцінка надається протягом 2 робочих днів.
Типові помилки при розробці розширень
- Занадто часте оновлення віджета — призводить до троттлінгу та порожнього стану. Рекомендуємо інтервал не менше 15 хвилин (див. Apple Human Interface Guidelines, WidgetKit documentation).
- Ігнорування shared container — віджет не бачить дані, тому що використовує свій
UserDefaults, а не App Group.
- Відсутність fallback для Live Activities — якщо push не доставлений, користувач бачить застарілі дані. Потрібен механізм періодичного опитування через
Activity.update з pushType: nil.
- Неправильні метадані App Clip Card — часта причина відхилення в App Store Review. Наприклад, некоректний URL або відсутній значок.
Зв'яжіться з нами, щоб оцінити, яке розширення підходить вашому додатку. Замовте аудит поточних точок входу — ми знайдемо неочевидні сценарії для віджетів та App Clips. Отримайте консультацію інженера з архітектури вже сьогодні. Гарантуємо проходження App Store Review з першого разу — наш досвід підтверджений десятками успішних публікацій.
