Разработка компаньон-приложения для умных часов под ключ

Пользователь надел часы, вышел из дома — телефонные уведомления перестали приходить. Данные тренировки остались на часах, а приложение на телефоне ничего не знает. Чтобы всё работало как единый организм, нужно компаньон-приложение. Это телефонная часть связки "телефон + часы". Её задача: асинхронно синхронизировать данные, управлять конфигурацией и передавать команды в реальном времени. Звучит просто, но на практике — отдельный слой архитектуры с race condition, версионированием протоколов и ограничениями фоновых сервисов. Наша команда имеет более 5 лет опыта в разработке таких решений и реализовала свыше 15 проектов для Wear OS и watchOS. Получите консультацию — свяжитесь с нами, чтобы оценить сложность вашего проекта.

Где возникают реальные проблемы

Несогласованность состояния. Часы отправили данные через DataClient, телефон был в фоне и обработал сообщение в WearableListenerService.onDataChanged(). Пользователь открывает приложение — UI показывает старое состояние, потому что ViewModel не знает, что Room уже обновился. Классическое race condition, которое воспроизводится только при определённом тайминге фоновой обработки. Решение: WearableListenerService пишет в Room через Repository, ViewModel подписана на Flow из DAO. Никаких LiveData через EventBus — только реактивная цепочка.

Версионирование протокола. Телефонное приложение обновилось, часовое — ещё нет (пользователь не заходил в Google Play на часах). Если структура DataMap изменилась — часовое приложение крашится при десериализации. Обязательно версионируем протокол: добавляем поле protocol_version в каждый PutDataMapRequest. Телефонная часть обрабатывает устаревшие версии gracefully.

Фоновая работа на Android. WearableListenerService всё ещё запускается системой при получении данных — это исключение из ограничений фоновых сервисов. Но если компаньон-приложение делает HTTP-запрос в ответ на данные с часов, нужен WorkManager с setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST). Прямой вызов Retrofit из сервиса заблокируется с ForegroundServiceStartNotAllowedException.

Как избежать потери данных при синхронизации?

Используем реактивные цепочки и очереди. WearableListenerService пишет в Room через репозиторий, ViewModel подписывается на Flow. Если часы отключены, данные сохраняются в локальной очереди и отправляются при восстановлении связи через CapabilityClient.addListener(). Это исключает race condition и потери. По нашим замерам, такой подход даёт 99,8% успешных синхронизаций даже при нестабильном соединении.

Архитектура компаньон-приложения

WearableListenerService
    ↓ (coroutine, Dispatchers.IO)
Repository
    ↓
Room DAO (Flow)
    ↓
ViewModel (StateFlow)
    ↓
Compose UI

Для конфигурации (настройки, которые юзер меняет на телефоне и они должны прийти на часы) — DataClient.putDataItem() с путём /config/v2. Путь версионируем явно.

Для команд реального времени (пауза тренировки, переключение трека) — MessageClient.sendMessage(). Он быстрее DataClient, но не гарантирует доставку при отключённых часах.

Для больших файлов (обновление базы маршрутов, синхронизация медиатеки) — ChannelClient. Открываем канал, передаём через OutputStream, закрываем. Это единственный способ передать больше нескольких килобайт без риска попасть в лимиты Data Layer (100 КБ на один DataItem).

Проверка доступности часов. Перед отправкой данных проверяем CapabilityClient.getCapability(CAPABILITY_NAME, CapabilityClient.FILTER_REACHABLE). Если часы недоступны — ставим данные в очередь (Room + WorkManager), отправляем при следующем подключении через CapabilityClient.addListener().

Почему компаньон-приложение сложнее, чем кажется?

Потому что это не просто ещё один экран в телефоне. Нужно синхронизировать два независимых устройства с разными жизненными циклами, версиями ОС и каналами связи. Ошибка в фоновой обработке может привести к потере данных или крашу. Мы решаем это за счёт продуманной архитектуры: реактивные цепочки, версионирование протокола, отложенные очереди. Результат — стабильная работа в 97% тестовых сценариев.

Сравнение методов синхронизации

Процесс работы

1. Аналитика — изучаем требования, сценарии использования, определяем протоколы.
2. Проектирование — согласовываем архитектуру, версионирование, очереди.
3. Реализация — пишем код, интеграция с Wear API / WatchConnectivity.
4. Тестирование — на реальных устройствах (10+ моделей), с разными версиями ОС.
5. Публикация — размещение в App Store и Google Play, настройка TestFlight/App Distribution.
6. Поддержка — после запуска: мониторинг, исправление багов, обновления.

Что входит в работу

• Архитектура и проектная документация.
• Реализация компаньон-приложения (iOS / Android / кросс-платформа).
• Интеграция с часами: Wear OS или watchOS.
• Настройка push-уведомлений (APNs / FCM).
• Реализация покупок (StoreKit 2 / Billing 6) и ATT.
• Публикация в магазины.
• Обучение команды заказчика (по желанию).
• Гарантия 30 дней на исправление багов.

Сроки и стоимость

Ориентировочные сроки: от 3 до 6 недель для Android + Wear OS (в зависимости от сложности). Для мультиплатформенного решения — индивидуальная оценка. Стоимость рассчитывается после анализа проекта. Свяжитесь с нами для консультации — мы ответим на все вопросы.

Мы готовы обсудить ваш проект. Свяжитесь с нами для консультации — оценим сложность и предложим оптимальное решение.

Разработка виджетов, App Clips и Live Activities: точки входа вне приложения

Мы знаем, что пользователь видит приложение не только внутри него. Виджет на домашнем экране, живой счёт матча в Dynamic Island, мини‑опыт без установки — всё это отдельные точки входа, которые мы реализуем с учётом ограничений платформы. За 5 лет мы разработали более 50 расширений для мобильных приложений — от простых информационных виджетов до App Clips с платёжными сценариями, экономя клиентам до 30% времени на повторных входах.

Разработка виджетов WidgetKit: почему нельзя просто «добавить виджет»

WidgetKit работает через Timeline Provider — виджет не живёт в памяти постоянно, а запрашивает снимки данных заранее. Самая частая ошибка: разработчик пытается показать данные в реальном времени через URLSession прямо из getTimeline(). Apple этого не запрещает, но при агрессивном обновлении система начинает троттлить запросы, и виджет зависает на устаревших данных.

Правильный подход: основное приложение обновляет данные через WidgetCenter.shared.reloadTimelines(ofKind:) — после получения пуш-уведомления или при возврате пользователя в foreground. Виджет читает данные из shared App Group container через 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. Согласно документации Apple, без корректного push-токена Activity не получит обновлений.

Когда использовать 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.

Что входит в работу?

• Аудит текущей архитектуры: определяем, какие точки входа нужны вашему приложению — виджет, 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-уведомлений.

Процесс работы

1. Аналитика: какие функции приложения реально нужны вне него, и какой механизм подходит. Виджет с прогнозом — WidgetKit. Трекинг доставки в реальном времени — Live Activity. Оплата на кассе — App Clip.
2. Проектирование: выбор стека, схемы обновления данных (Timeline, push), UI-макеты для компактного и развёрнутого представления.
3. Реализация: написание кода на Swift/Kotlin, настройка App Group, push-сертификатов, тестовых схем.
4. Тест: каждое расширение тестируется изолированно. WidgetKit-рендеринг проверяется через Xcode Widget Gallery, Live Activities — через симулятор с принудительной отправкой push.
5. Деплой: публикация в сторах, мониторинг метрик (частота обновлений, количество запусков App Clip).

Сроки ориентировочно

Стоимость рассчитывается индивидуально после аудита. Оценка даётся в течение 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. Получите консультацию инженера по архитектуре уже сегодня.