PRIMARY AUDIENCE
Power users with watches in the Moyoung / Da Fit-compatible family—potentially including some GoBoult, Drift, Colmi, and Fire-Boltt devices—who are comfortable testing an alternative companion app.
Smartwatch companion · Moyoung / Da Fit BLE
Watch / NF Watch
Android wearable app
A native Android alternative for specific Da Fit-compatible wearables, with local-first sync and phone-finding tools.
Interface overview
17Stable APK asset downloads
18 across two artifactsAll release asset downloads
4 stars · 0 forks · 0 open issuesRepository snapshot
v1.0.0 · 12 Aug 2026Latest stable
01 / WHY
The problem I chose to solve
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
Many budget smartwatches rely on a vendor companion app that may have limited user control, inconsistent background reconnection, or a cloud-connected experience. The connection protocol can also be a hidden barrier to building a better companion app for a family of devices.
Watch implements the Moyoung / Da Fit Bluetooth Low Energy protocol in a native Kotlin application. The approach is to control the BLE connection lifecycle, local persistence, Health Connect handoff, and phone-finding SOS behavior directly in Android, while keeping the documented health-related data offline rather than requiring a separate vendor account.
02 / WHO IT SERVES
Where it fits in the real world
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
WHAT MAKES IT DISTINCT
- Native BLE protocol work rather than a web wrapper
- Auto-connect and reconnection mechanisms designed around background execution
- Room/DataStore storage and local-first data handling
- Health Connect integration documented for syncing selected health metrics
- Phone-finding SOS combines audio, flashlight, and vibration patterns
03 / PRODUCT SURFACE
What the system actually does
An overview of key capabilities and system features.
CAPABILITY / 01
BLE connection
Specialized GATT auto-connect and reconnection recovery logic.
CAPABILITY / 02
Phone finder
Watch-triggered alert mode with sound and synchronized flashlight/vibration behavior.
CAPABILITY / 03
Health Connect
Two-way integration with Android’s health data store is documented.
CAPABILITY / 04
Local persistence
Room and DataStore support device-side state.
CAPABILITY / 05
Modern interface
Jetpack Compose / Material 3 UI with a dark glassmorphism visual direction.
04 / SYSTEM MAP
Architecture & data flow
Architecture and system flow overview.
LAYER / 01
Moyoung-compatible watch
Wearable advertises a BLE profile understood by the app.
LAYER / 02
Android BLE client
The Kotlin app establishes and maintains GATT communication.
LAYER / 03
Local data layer
Room/DataStore persists configuration and supported readings.
LAYER / 04
Android integrations
Health Connect sync and SOS phone controls use platform APIs and permissions.
IMPLEMENTATION STACK
Kotlin, Jetpack Compose, BLE GATT / Moyoung protocol, Room, DataStore, WorkManager, Android Health Connect, R8/ProGuard.
KotlinJetpack ComposeBLE GATT / Moyoung protocolRoomDataStoreWorkManagerAndroid Health ConnectR8/ProGuard.
05 / ENGINEERING JUDGMENT
Decisions behind the implementation
Engineering choices and design decisions behind the implementation.
- Work below the standard UI layer to address the connection reliability problem.
- Keep recorded health data local and bridge through Android’s native Health Connect store.
- Constrain the product to the protocol family it actually implements instead of claiming universal compatibility.
06 / SCOPE & BOUNDARIES
Technical Considerations
Key technical details and system scope considerations.
- Compatibility depends on the exact watch model, firmware, phone, and Bluetooth implementation; “Da Fit-compatible” is a useful screening clue, not a universal guarantee.
- The documented “unstoppable” high-volume alert behavior may be constrained by Android audio policies, OEM changes, and permissions; verify behavior across devices and keep an owner-controlled stop path clear.
- The latest stable release has 17 APK asset downloads. That is an early technical project signal, not evidence of large-scale adoption.
07 / NEXT ITERATION
What I would improve next
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
NEXT / 01
Maintain a tested watch/phone/Android-version matrix.
NEXT / 02
Add reproducible BLE logs with personal identifiers stripped out.
NEXT / 03
Validate SOS stop and notification behavior for accessibility, safety, and platform compliance.
08 / SOURCES
Sources & Resources
Project repositories and resource links.