Разработка мобильного приложения для стартапа: как мы восстановили BLE-протокол фитнес-браслетов и запустили продукт без готового SDK

Заказчик — hardware-стартап из Москвы, выпускающий фитнес-браслеты и умные кольца под собственным брендом (сами устройства заказываются у китайского производителя).

Задача — разработка мобильного приложения для стартапа на iOS и Android, которое будет подключаться ко всем устройствам линейки по Bluetooth, собирать данные об активности пользователя и синхронизировать их с сервером.

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

Решение — мы отказались от неработающего SDK, разобрали BLE-протокол устройств «по байтам» и восстановили логику обмена данными напрямую, взяв управление на себя. Это пример того, как настоящая разработка IoT-решений выглядит на практике.

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

Подробнее о ходе работ и технических деталях — ниже.

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

На старте ситуация выглядела стандартно. Есть устройство, есть SDK от производителя — значит, остаётся реализовать мобильную разработку под iOS и Android и подключить API.

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

SDK существовал формально, но не давал управляемости: устаревшая Android-часть, закрытая iOS-библиотека, ошибки в коде и отсутствие прозрачной структуры данных.

Это означало, что при работе с Bluetooth Low Energy невозможно было гарантировать корректную синхронизацию данных. Устройство становилось неконтролируемым источником, что критично для разработки приложений для носимых устройств и IoT-продуктов.

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

Мы не начали с интерфейсов. Сначала нужно было понять, можно ли вообще стабильно работать с устройством и корректно обрабатывать биометрические данные.

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

Поэтому мы исключили его из решения и перешли к прямой работе с BLE-протоколом.

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

В классической модели Bluetooth Low Energy устройство предоставляет набор характеристик с понятной структурой данных. Это упрощает интеграцию с IoT-устройствами и разработку приложений для  носимых устройств.

В этом проекте структура отсутствовала.

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

Фактически BLE использовался как транспорт без логики.

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

Без документации мы начали разбирать систему на уровне протокола.

Сначала проанализировали Android-часть SDK и извлекли базовые команды. Это дало отправную точку, но не позволило собрать полную картину.

Дальше перешли к iOS-библиотеке: декомпилировали её, перевели в читаемый вид и начали восстанавливать логику формирования запросов и обработки ответов.

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

Таким образом мы восстановили BLE-протокол и сформировали управляемый слой взаимодействия.

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

После восстановления логики BLE мы собрали прототип. Без интерфейсов — только проверка архитектуры мобильного приложения и корректности синхронизации данных.

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

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

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

В результате появился универсальный слой работы с Bluetooth Low Energy, который не зависит от конкретного устройства и может использоваться для интеграции с разными типами девайсов.

К концу этапа заказчик из Москвы получил главное — контролируемую систему, в которой синхронизация данных предсказуема, а архитектура готова к развитию.

Когда техническая часть стала стабильной, задача вышла за рамки интеграции.

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

Это меняет подход к разработке.

Мы отказались от модели, где приложение просто отображает данные. В проектах с обработкой биометрических данных это не даёт ценности.

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

Так формируется продукт, а не интерфейс.

Решения, заложенные на первом этапе, позволили сразу выйти за пределы одного устройства.

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

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

После формирования пользовательской ценности мы связали её с монетизацией.

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

Таким образом монетизация основана не на доступе к данным, а на их интерпретации.

Дополнительно заложены сценарии роста вовлечённости, которые можно развивать без изменения архитектуры.

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

Мы восстановили BLE-протокол, выстроили собственный слой работы с Bluetooth Low Energy и обеспечили предсказуемую синхронизацию данных. Это позволило реализовать мобильную разработку под iOS и Android без зависимости от SDK.

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

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

Он не зависит от ограничений конкретного устройства и может развиваться вместе с бизнесом.

Вот как мы работаем, когда задача оказывается сложнее, чем казалось на старте:

● Не верим в «волшебные» SDK — проверяем протокол на уровне байтов и восстанавливаем логику работы устройства.

● Слышим боль стартапа: срыв сроков, зависимость от OEM-производителя, риск потери инвестиций.

● Уменьшение неопределённости — наша цель: заказчик получает предсказуемую систему, а не «чёрный ящик».

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

● Разработка IoT-решений — наш подход: архитектура под класс устройств, а не под одну модель, чтобы продукт мог расти.

● Попутно проверяем масштабируемость решения — такого задела от типовой мобильной разработки можно не ждать.

Вам нужен не просто код для фитнес-приложения, а работающая интеграция с устройством, которая снимет риски и не развалится на масштабировании? Оставляйте заявку.