Фитнес-браслеты и умные кольца без SDK: приложение с монетизацией

Заказчик обратился к нам с задачей разработать кроссплатформенное мобильное приложение для фитнес-браслета, закупленного у китайского производителя. Приложение должно было подключаться к устройству по BLE, считывать пользовательские показатели — пульс, шаги, сон и другие метрики — и передавать их в API клиента.

На старте задача выглядела как стандартная интеграция с носимым устройством. Но уже на этапе анализа стало понятно, что основная сложность — в самом устройстве. SDK оказался устаревшим и нестабильным: код содержал ошибки, документация не объясняла логику работы, а часть данных была недоступна для интерпретации.

Дополнительно ситуацию усложнял нестандартный BLE-протокол: устройство работало через ограниченное количество полей, а обмен данными происходил в бинарном виде без описания структуры.

В результате перед нами стояла двойная задача: сначала восстановить логику работы устройства и обеспечить стабильный обмен данными, а затем построить на этой базе мобильное приложение, готовое к развитию и масштабированию под разные типы носимых устройств.

Смарт-устройства поставлялись с SDK 2017 года, который на практике оказался непригоден для разработки. Android-часть была написана на устаревшей Java, iOS — на Objective-C с полностью закрытым кодом, часть функций не работала, а комментарии были на китайском и не давали понимания логики. В таком виде SDK не позволял понять, как устройство ведёт себя и какие данные реально можно получить.

Чтобы снизить риски, мы вместе с заказчиком пересобрали подход к разработке и разделили проект на два этапа.

Сначала сделали MVP без дизайна — нам было важно проверить базовую вещь: можно ли стабильно подключаться к устройству, получать данные и передавать их в API. На этом этапе мы фактически восстановили логику работы устройства и выстроили собственный слой взаимодействия с ним, не опираясь на SDK.

После того как убедились, что устройство работает предсказуемо, перешли ко второму этапу — разработке полноценного кроссплатформенного приложения. Здесь уже сфокусировались на пользовательском опыте, интерфейсе и логике продукта, сохранив при этом управляемую архитектуру для дальнейшего развития.

В теории работа с BLE выглядит довольно просто. Устройство обнаруживается, приложение подключается к нему, запрашивает доступные характеристики и дальше читает или записывает данные по понятным идентификаторам — пульс, шаги, давление и другие показатели. Обычно таких характеристик несколько десятков, и с ними можно работать как с готовой структурой.

В нашем случае всё оказалось иначе.

Производитель сильно упростил реализацию и оставил всего два поля: одно для отправки запроса и одно для получения ответа. Это означало, что никакой структуры данных нет — есть только поток байтов, который нужно правильно сформировать и так же правильно расшифровать.

BLE в принципе не использует привычные форматы вроде JSON или XML. Устройство принимает набор чисел и возвращает другой набор. Если не понимать, что означает каждый байт, работать с такими данными невозможно.

Поэтому основной задачей стало не подключение к браслету, а восстановление логики протокола.

Документации не было, и все бинарные запросы пришлось собирать вручную. Сначала мы попробовали извлечь часть логики из Android-кода на Java. Оттуда удалось получить несколько команд и сопоставить их с реальными показателями, но этого было недостаточно, чтобы собрать полную картину.

Тогда мы пошли глубже и начали разбирать iOS-библиотеку. Она была закрыта и собрана под архитектуру Darwin, поэтому мы декомпилировали её, перевели в ассемблер, а затем в C-код с помощью Ghidra. Это позволило понять, как именно формируются запросы и как устройство кодирует ответы.

Дальше всё проверялось на практике. Мы отправляли команды, анализировали ответы и сопоставляли их с тем, что показывает браслет. Постепенно удалось восстановить структуру данных и понять, какие последовательности байт соответствуют конкретным метрикам.

Во время тестирования встречались и совсем неочевидные вещи. Например, поля с названиями вроде HeartRateReability_TestData, которые не давали никакого понимания, что за ними стоит. Мы собрали такие случаи и передали заказчику, чтобы уточнить их у производителя.

Позже выяснилось, что у китайской стороны есть обновлённая версия SDK на Flutter. Она тоже требовала доработок, но уже содержала рабочие исходники. Это помогло уточнить часть параметров и окончательно собрать логику протокола.

В итоге мы сделали главное — превратили «чёрный ящик» в понятную систему, с которой можно стабильно работать и строить продукт дальше.

Когда стало понятно, как устроен протокол и как получать данные, важно было ответить на следующий вопрос — будет ли это стабильно работать не в теории, а в реальном использовании.

На этом этапе мы сознательно не шли в дизайн и полноценный продукт. Сначала нужно было убедиться, что вся цепочка работает: устройство подключается, данные приходят, корректно обрабатываются и передаются в API.

Мы сделали минимальное приложение, в котором проверяли каждый шаг отдельно. Подключение к браслету, отправка команд, получение данных, их расшифровка — всё тестировали как независимые сценарии, чтобы быстро находить и исправлять ошибки.

Это позволило поймать ключевые проблемы заранее, а не уже после релиза, когда они начинают влиять на пользователей.

Параллельно мы начали выстраивать архитектуру так, чтобы она не была привязана к конкретному устройству. Уже на этом этапе стало понятно, что заказчик будет развивать линейку устройств, и приложение должно уметь работать не только с браслетом.

Поэтому слой работы с BLE сделали универсальным. Он не зависит от конкретного девайса и позволяет подключать разные устройства с похожей логикой передачи данных.

Это решение оказалось важным позже, когда в продукт добавились умные кольца с биометрическими данными. Их удалось встроить в существующую систему без переработки логики взаимодействия.

К концу этапа у заказчика было не просто MVP-приложение, а уверенность, что устройство работает стабильно, данные передаются корректно, и на этой базе можно строить полноценный продукт.

По сути, на этом этапе мы сняли главный риск проекта — неопределённость.

Когда стало понятно, что устройство работает стабильно и данные можно получать без сюрпризов, задача поменялась. До этого мы отвечали на вопрос «это вообще можно сделать». Теперь — «будет ли этим кто-то пользоваться».

Здесь легко пойти по самому простому пути — сделать приложение, которое просто показывает цифры. Пульс, шаги, сон — всё на месте, формально задача закрыта. Но такие продукты не живут. Пользователь не открывает приложение ради цифр — он хочет понять, что с ним происходит.

Поэтому мы изначально пошли в другую сторону и начали собирать не трекер, а ассистента. Приложение должно было не просто отображать данные, а объяснять их: что означает текущая нагрузка, нормальный ли сон, есть ли перегруз или не довосстановление. По сути, переводить язык метрик в понятные действия.

При этом быстро стало ясно, что главная проблема — не в расчётах, а в подаче. Биометрия сама по себе сложная, особенно сон. Это не одна цифра, а смена фаз, графики, динамика за ночь. Если показать всё сразу, пользователь просто закроет экран.

Поэтому мы начали упрощать. На главном экране оставили только ключевые показатели — в виде виджетов, без лишних деталей. Человек открывает приложение, за несколько секунд понимает своё состояние и идёт дальше. Если нужно глубже — можно провалиться в детали.

Самым сложным оказался экран сна. Его нельзя было собрать из готовых компонентов — пришлось делать свои графики, чтобы контролировать, как именно отображаются фазы и переходы. Важно было не «красиво нарисовать», а сделать так, чтобы это было понятно без объяснений.

Параллельно решали вопрос с данными. Мы сделали локальную базу основной точкой работы приложения: все показатели сначала сохраняются на устройстве, а уже потом синхронизируются с сервером. Это позволило сделать интерфейс быстрым и не зависеть от интернета — пользователь видит данные сразу.

Дальше продукт начали связывать с деньгами. Базовый функционал сделали бесплатным — это вход и привычка. Подписка даёт дополнительную ценность: аналитику, рекомендации, возможность управлять нагрузкой.

Важно, что пользователь платит не за цифры, а за понимание.

Со временем продукт начал расти. Заказчик добавил в линейку умные кольца, которые тоже передают биометрию. Их нужно было подключать и синхронизировать с тем же приложением.

И здесь как раз сработало то, что мы заложили на первом этапе. Нам не пришлось ничего переделывать — мы просто расширили существующую логику работы с устройствами.

В этот момент стало окончательно понятно, что получилось не просто приложение под браслет, а продукт, который можно развивать дальше.

Заказчик пришёл с задачей сделать приложение для фитнес-браслета, но на практике оказалось, что с устройством нельзя стабильно работать из-за устаревшего SDK и отсутствия документации.

Мы восстановили BLE-протокол, взяли под контроль работу с данными и построили собственный слой взаимодействия с устройствами. На этой базе разработали кроссплатформенное приложение и заложили архитектуру, которая позволяет подключать не только браслеты, но и другие носимые устройства — в том числе умные кольца.

Параллельно превратили техническое решение в продукт: с понятным интерфейсом, пользовательскими сценариями и моделью монетизации через подписку.

В результате заказчик получил не интеграцию с устройством, а масштабируемый продукт, готовый к запуску и развитию.