Update many of the concrete CareKit types to Hashable for SwiftUI

[cbaker6]

Many of the types in CareKit are structs that conform to Equatable, but not Hashable. My guess is because these types pre-date SwiftUI. This causes issues when using the respective types to update a SwiftUI view. See a bug that is mentioned here for reference netreconlab/CareKitSample-ParseCareKit#145 (comment)

Can types such as OCKAnyEvent, OCKPatient, OCKOutcome, etc. be made Hashable? This is harder than it seems as it will initially break a lot of the CareKit code.

Also, a nice to have is to have CareStoreFetchedResults made Hashable and to be able to get return types of [OCKPatient], [OCKCarePlan], etc. Note, I'm not suggesting that protocols such as OCKAnyPatient conform to Hashable (though this would fix this issue for all types entirely) as that will cause additional breaks in CareKit and possibly break developers code if they created their own types by conforming.

A workaround along with conformance for many of the types are in our Essentials framework (the files typically end in ...+Hashable.swift): https://github.com/netreconlab/CareKitEssentials/tree/main/Sources/CareKitEssentials/Extensions

[HussainAther]

this is a good one. ty for raising id.

adding the Hashable conformance to key types like OCKAnyEvent, OCKPatient, and OCKOutcome would definitely enhance SwiftUI interoperability. I’ve encountered similar limitations when trying to use these types in ForEach or bind them to SwiftUI views that rely on Identifiable & Hashable conformance.

the linked workaround via CareKitEssentials is v helpful and makes it clear this is achievable in practice, even if the initial change may introduce breaking updates. One way to minimize disruption could be to introduce conditional conformance where possible or progressively phase in the changes behind a feature flag (if that aligns with the framework’s philosophy).

I also agree it’s reasonable not to require protocol-level Hashable conformance (OCKAnyPatient, etc.) to avoid broader breakage.

Happy to help explore a draft PR or test changes locally if needed!

Thanks again for proposing this.