Backwards compatibility support strategy for CareKit - observing now as N - 1 which is quite restrictive compared to ResearchKit

[SwiftNativeDeveloper]

Thanks for addressing the issues with Xcode 26 and moving towards Swift 6. I did see in that release note that the minimum targets are now N - 1. Was there a specific technical reason to drop support for iOS 17 and watchOS 10, or just a maintenance reduction effort?

The applications I support are N - 2 (26, 18, 17) so we still can't take the new library update as much as we need to. Any commentary will help me inform product owners and the CareKit community at large, what the direction of backwards compatibility will be going forward.

Thanks in advance!

[gavirawson-apple]

I'm sorry that created an issue for you @SwiftNativeDeveloper. The primary reason we moved to iOS 18+ is because we wanted to access the new Mutex type as a tool to help move towards Swift 6 compatibility. There are a few ways to synchronize lower level code (Actor, Mutex, Lock, DispatchQueue, etc.), but using a Mutex is a modern tool that integrates well with strict concurrency checks, and crucially does not create async call sites like its Actor counterpart. Marking public API as async would have introduced new complexity and potentially caused unexpected behaviors due to nuances specific to Concurrency.

Do let me know if there's anything I can do to help you and the applications you support. Maybe we can brainstorm and spin up a one off solution here to help address any problems you have.