❌

Reading view

Fitbit Now Syncs With Apple Health

Juli Clover:

Google Health (previously the Fitbit app) collects fitness, sleep, and wellness data from a connected wearable device. Steps, distance traveled, heart rate, sleep, and more can now be added to Apple Health. As noted on Reddit, some data such as HRV doesn't transfer over.

[…]

Syncing can be enabled after downloading the update by selecting Connections, choosing Apps and services, and then adding Apple Health.

My wife is a longtime Fitbit user. A few weeks ago, some family and friends started a friendly competition to see who could get the most steps. They’re all Fitbit users, too. Then she wanted to start comparing step counts with me, but I have an Apple Watch. I thought this would be no problem because the Health app has a sharing feature, and Fitbit and HealthKit have both been around forever. I was shocked to learn that there has never been any syncing. I don’t really understand the reason for this, as it seems like it would make the Fitbit more valuable.

It looks like the syncing part is now solved, but we still can’t automatically compare our steps. We’ve both tried inviting each other to share step counts and some other metrics multiple times over the last several weeks, and it has never worked. Either the invitation doesn’t arrive or the app just spins forever when trying to accept it.

Previously:

  •  

NSPasteboard Crashes When Handling File Promises

Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.

  •  
❌