
Разработкамобильногоприложениядляфитнес-браслетовиумныхколецсинтеграциейBLE:восстановилипротоколустройстваизапустилипродуктбезSDK
Заказчик — компания, выпускающая фитнес-браслеты и умные кольца под собственным брендом (сами устройства заказываются у китайского производителя).
Задача — разработать мобильное приложение для iOS и Android, которое будет подключаться ко всем устройствам линейки по Bluetooth, собирать данные об активности пользователя и синхронизировать их с сервером.
Проблема — китайский производитель предоставил SDK (набор инструментов для разработки), но он оказался практически бесполезным: устаревший код, закрытые участки без доступа, отсутствие внятного описания того, как именно устройства передают данные. Работать «вслепую» через такой SDK было невозможно — данные о шагах, пульсе и других метриках приходили некорректно или терялись при передаче.
Решение — мы отказались от неработающего SDK, разобрали BLE-протокол устройств «по байтам» и восстановили логику обмена данными напрямую, взяв управление на себя.
Результат — вместо непредсказуемого «чёрного ящика» получили стабильно работающее приложение и универсальную архитектуру, которая одинаково уверенно работает как с фитнес-браслетами, так и с умными кольцами.
Подробнее о ходе работ и технических деталях — ниже.
ИзнепредсказуемогоIoT-устройства—встабильноемобильноеприложениеиэкосистемуносимыхустройств
К нам пришёл заказчик с задачей: разработать мобильное приложение для фитнес-браслета и довести продукт до релиза. Речь шла не просто о клиентском интерфейсе, а о полноценной интеграции с устройством через Bluetooth Low Energy и передаче данных в API.
На старте ситуация выглядела стандартно. Есть устройство, есть SDK от производителя — значит, остаётся реализовать мобильную разработку под iOS и Android и подключить API.
Но довольно быстро стало понятно, что ограничение не в самой разработке приложения. Ограничение — в устройстве и в том, как устроена интеграция с BLE.
SDK существовал формально, но не давал управляемости: устаревшая Android-часть, закрытая iOS-библиотека, ошибки в коде и отсутствие прозрачной структуры данных.
Это означало, что при работе с Bluetooth Low Energy невозможно было гарантировать корректную синхронизацию данных. Устройство становилось неконтролируемым источником, что критично для разработки приложений для wearable-устройств и IoT-продуктов.
При этом заменить устройство было нельзя — это ломало экономику проекта. Поэтому задача сместилась: не просто сделать приложение для фитнес-браслета, а выстроить управляемую интеграцию с BLE и взять под контроль сам протокол.
Этап1.РазработкаинтеграциисBLEивосстановлениепротоколаустройства
Мы не начали с интерфейсов. Сначала нужно было понять, можно ли вообще стабильно работать с устройством и корректно обрабатывать биометрические данные.
Собрали минимальный сценарий: подключение по Bluetooth Low Energy, получение данных и попытка связать их с API. Уже на этом этапе стало очевидно, что SDK не позволяет выстроить предсказуемую архитектуру мобильного приложения.
Поэтому мы исключили его из решения и перешли к прямой работе с BLE-протоколом.

КогдаBLE-протоколнедаётструктуры
В классической модели Bluetooth Low Energy устройство предоставляет набор характеристик с понятной структурой данных. Это упрощает интеграцию с IoT-устройствами и разработку приложений для wearable-устройств.
В этом проекте структура отсутствовала.
Устройство работало через две точки: одна принимала запрос, другая возвращала ответ. Внутри — бинарный поток без описания. Это означало, что любая синхронизация данных превращалась в задачу интерпретации байтов.
Фактически BLE использовался как транспорт без логики.
Это создаёт высокий риск: любая ошибка в понимании формата приводит к некорректной обработке биометрических данных и нестабильной работе приложения.

Реверс-инжинирингBLE-протоколаивосстановлениелогики
Без документации мы начали разбирать систему на уровне протокола.
Сначала проанализировали Android-часть SDK и извлекли базовые команды. Это дало отправную точку, но не позволило собрать полную картину.
Дальше перешли к iOS-библиотеке: декомпилировали её, перевели в читаемый вид и начали восстанавливать логику формирования запросов и обработки ответов.
Недостающие элементы проверяли экспериментально — через реальные запросы к устройству и анализ ответов. Это позволило сопоставить бинарные данные с конкретными метриками и выстроить собственную модель обработки.
Таким образом мы восстановили BLE-протокол и сформировали управляемый слой взаимодействия.
Позже был найден обновлённый SDK на Flutter. Он не решал задачу прозрачности, но помог уточнить отдельные параметры. Мы использовали его как дополнительный источник данных.
Похожиепроекты


Проверкаархитектурымобильногоприложениянапрактике
После восстановления логики BLE мы собрали прототип. Без интерфейсов — только проверка архитектуры мобильного приложения и корректности синхронизации данных.
Важно было убедиться, что вся цепочка работает стабильно: подключение, отправка команд, получение данных и их декодирование.
Такой подход позволил выявить ошибки до этапа полноценной разработки приложения для умных устройств.
Параллельно мы заложили архитектуру не под конкретный браслет, а под класс устройств. Это критично для проектов, связанных с IoT и wearable-устройствами, где устройства часто имеют нестабильные SDK.
В результате появился универсальный слой работы с Bluetooth Low Energy, который не зависит от конкретного устройства и может использоваться для интеграции с разными типами девайсов.
К концу этапа заказчик получил главное — контролируемую систему, в которой синхронизация данных предсказуема, а архитектура готова к развитию.
Этап2.Превратилиразработкуприложениявпродукт
Когда техническая часть стала стабильной, задача вышла за рамки интеграции.
Нужно было не просто реализовать мобильное приложение, а создать продукт, который пользователь будет регулярно использовать.
Это меняет подход к разработке.
Мы отказались от модели, где приложение просто отображает данные. В проектах с обработкой биометрических данных это не даёт ценности.
Приложение стало работать как ассистент: оно не только собирает данные с устройства, но и интерпретирует их, помогая пользователю понять состояние и принять решения.
Так формируется продукт, а не интерфейс.

Архитектураподразработкуприложенийдляносимыхустройств
Решения, заложенные на первом этапе, позволили сразу выйти за пределы одного устройства.
Приложение проектировалось как платформа для работы с wearable-устройствами, включая фитнес-браслеты и умные кольца. Это особенно важно для IoT-продуктов, где линейка устройств со временем расширяется.
Архитектура мобильного приложения позволяет подключать новые устройства без переработки базовой логики.
Связкапродуктаибизнес-модели
После формирования пользовательской ценности мы связали её с монетизацией.
Базовый функционал остаётся бесплатным и отвечает за привлечение пользователей. Платная часть строится вокруг аналитики, рекомендаций и более глубокой работы с данными.
Таким образом монетизация основана не на доступе к данным, а на их интерпретации.
Дополнительно заложены сценарии роста вовлечённости, которые можно развивать без изменения архитектуры.
Чтовитогеполучилось
Заказчик пришёл с задачей разработки приложения для фитнес-браслета и устройством, с которым невозможно было выстроить стабильную интеграцию.
Мы восстановили BLE-протокол, выстроили собственный слой работы с Bluetooth Low Energy и обеспечили предсказуемую синхронизацию данных. Это позволило реализовать мобильную разработку под iOS и Android без зависимости от SDK.
На этой базе было создано приложение и архитектура, подходящая для разработки под wearable-устройства и интеграции с IoT-экосистемами, включая умные кольца.
В результате получился полноценный продукт — готовый к запуску, с понятной логикой монетизации и возможностью масштабирования.
Он не зависит от ограничений конкретного устройства и может развиваться вместе с бизнесом.

Технологии
Кейсы,которымимыгордимся


