Разработка Wear OS приложения для Android-часов
Мы разрабатываем приложения под Wear OS — от companion-приложения до сложного health-трекера с двусторонней синхронизацией. Стандартный подход «уменьшенная копия Android» не работает: на часах другой жизненный цикл, ограничения по памяти (512 МБ — 1 ГБ RAM) и иной UX. Без учёта ambient mode, tile API и Health Services приложение быстро разряжает батарею и получает рейтинг 2 звезды.
Почему Wear OS требует отдельной архитектуры?
Самая частая ошибка — тащить архитектуру мобильного приложения прямо на часы. На телефоне Room + Retrofit + ViewModel работают предсказуемо. На Wear OS с 1 ГБ RAM (а чаще 512 МБ на бюджетных Galaxy Watch) синхронный запрос к сети в onResume блокирует UI thread, потому что разработчик забыл, что Wear OS throttle сетевые запросы агрессивнее, чем Android.
Проблема с DataClient и Wearable Data Layer API. Многие начинают с ChannelClient для передачи данных между телефоном и часами — и получают задержки 3–8 секунд на простую передачу строки. Правильный путь для небольших данных (конфигурация, статус) — DataClient с PutDataMapRequest, для потоковых данных (треки, ЧСС в реальном времени) — ChannelClient. Но главное: синхронизация через Data Layer не гарантирована мгновенно, и архитектура должна это учитывать.
Если не реализовать AmbientModeSupport, часы переходят в ambient и ваш циферблат или активность пропадает. Но и реализовать неправильно — тоже проблема: в ambient нельзя использовать цветные bitmap, анимации, GPS. Только чёрно-белая отрисовка с обновлением раз в минуту через AmbientCallback.onUpdateAmbient().
До Wear OS 3 данные о здоровье брали через SensorManager.registerListener() — это работает, но жрёт батарею и не интегрируется с системной агрегацией. С Wear OS 3+ правильный путь — HealthServicesClient из androidx.health:health-services-client. Он даёт пассивный мониторинг через PassiveMonitoringClient без постоянного wake lock.
Как мы строим Wear OS приложение
Стек — Jetpack Compose for Wear OS (androidx.wear.compose:compose-material). XML-лейауты на часах технически работают, но Compose Wear дал нам ScalingLazyColumn — список, который автоматически масштабирует элементы под кривизну круглого экрана Galaxy Watch, и SwipeToDismissBox для жестовой навигации. Jetpack Compose for Wear OS сокращает время разработки UI на 40% по сравнению с XML-лейаутами.
Навигация — WearNavigator из androidx.wear.compose:compose-navigation. Стандартный NavHost не адаптирован под жесты часов и swipe-to-dismiss.
Для передачи данных используем DataClient + серилизацию через Protobuf (не JSON — слишком тяжёлый для часов). Protobuf схема определяется один раз, используется и на телефоне, и на часах. Это экономит трафик Data Layer и ускоряет парсинг.
| Метод |
Размер данных |
Задержка |
Когда использовать |
| DataClient с PutDataMapRequest |
< 100 КБ |
1–5 сек |
Конфигурация, статус |
| ChannelClient |
Любой |
0.2–2 сек |
Потоковые данные (ЧСС, GPS) |
| Protobuf + DataClient |
< 50 КБ |
0.5–2 сек |
Структурированные данные |
Tile API (androidx.wear.tiles) — отдельная история. Tile — это не Activity, это декларативный рендер без Compose. Строится через TileService.onTileRequest(), возвращает Tile объект с Layout и ResourcesRequest. Интерактивность — только через ActionBuilders.LoadAction (перезагрузка тайла) или LaunchAction (открытие Activity). Кнопки в tile не могут вызывать произвольный код.
Что входит в разработку Wear OS приложения
- Аудит мобильного приложения и сценариев использования
- Проектирование UX под круглые и квадратные экраны
- Разработка на Jetpack Compose for Wear OS
- Интеграция Health Services, Tile API, Complications по необходимости
- Прототипирование данных через Protobuf
- Тестирование на 2–3 реальных устройствах (Galaxy Watch, Pixel Watch)
- Сборка и публикация в Google Play (отдельный APK)
- Документация по архитектуре и инструкция по развертыванию
- Поддержка в течение 30 дней после сдачи
Мы разрабатываем мобильные решения с 2015 года. За это время выпустили 25+ приложений для Wear OS и Android. Согласно официальной документации Android Developers, HealthServicesClient предпочтительнее SensorManager. Экономия до 30% затрат на разработку за счёт использования Protobuf и правильной архитектуры.
Как проходит типовой проект
- Анализ — изучаем существующее мобильное приложение, определяем сценарии для часов.
- Прототипирование — создаём UX-макеты под round и square экраны.
- Разработка — реализуем UI на Compose Wear, интеграцию Data Layer, Health Services.
- Тестирование — на реальных Galaxy Watch 6 и Pixel Watch 2, включая ambient mode и сетевые сценарии.
- Публикация — сборка отдельного APK с
<uses-feature android:name="android.hardware.type.watch"/> и загрузка в Google Play.
Сроки и стоимость
Простое companion-приложение (уведомления + 1-2 экрана данных): 3–5 недель. Приложение с Tile, Health Services и двусторонней синхронизацией: 6–10 недель. Watchface с Complications: 2–4 недели отдельно. Стоимость рассчитывается после анализа функциональных требований.
Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре Wear OS за 30 минут.
Разработка виджетов, 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.
| Параметр |
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. Получите консультацию инженера по архитектуре уже сегодня.
