Skip to content

Fix strap reconnect after updates#195

Open
khalilkm01 wants to merge 2 commits into
NoopApp:mainfrom
khalilkm01:fix/strap-reconnect-after-updates
Open

Fix strap reconnect after updates#195
khalilkm01 wants to merge 2 commits into
NoopApp:mainfrom
khalilkm01:fix/strap-reconnect-after-updates

Conversation

@khalilkm01

Copy link
Copy Markdown
Contributor

Summary

  • Keep the installed macOS app as the single active NOOP instance so Xcode builds do not compete for the strap connection.
  • Rotate BLE scans between WHOOP 4.0 and WHOOP 5/MG when the saved model points at the wrong service.
  • Persist the WHOOP model that actually advertises so future reconnects start from the right family.

Why

After updates, the installed app and the Xcode build could both be running. That creates a real BLE contention path: the strap is visible, but live data may not settle because two app copies can try to own the connection. A stale selected model can also leave the app scanning only the wrong WHOOP service.

Validation

  • xcodebuild build -project Strand.xcodeproj -scheme Strand -configuration Debug -destination platform=macOS,arch=arm64 -derivedDataPath /Users/kabir/Library/Developer/Xcode/DerivedData/Strand-dmpzazadcpaekqgcchpueyusvgha COMPILER_INDEX_STORE_ENABLE=NO ONLY_ACTIVE_ARCH=YES ARCHS=arm64

No personal data or imported WHOOP exports are included.

Updates could leave the Xcode build and installed app running at the same time, so both processes could compete for the WHOOP BLE connection.

Keep the installed macOS app as the single active instance, rotate scans between WHOOP 4.0 and 5/MG when the selected service is stale, and persist the model that actually advertises.
@khalilkm01 khalilkm01 marked this pull request as ready for review June 13, 2026 02:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant