Issue with raising minimum supported OS

[luppoalberto111]

Problem

Recently, ResearchKitOnFHIR and ResearchKit fork have received an update in which the minimum required iOS version is changed from v15 to v17. This was unfortunate for us because we still need to support lower iOS versions.

I tried to lower down the version in both libraries and everything seems to work fine, even unit tests so I'm not quite sure if this change was necessary.

In case that's necessary, libraries should increment the major version and not just the minor number. In this example, both libraries dropped 2 generations of operating systems and yet incremented just minor.

For us, it means that we have difficulties to update other libraries while keeping the old version of ResearchKitOnFHIR which is sad 😢.

Solution

There are two action points from my side:

1. ResearchKit fork can be lowered down to iOS15 without any impact on the rest of the libraries.
2. ResearchKitOnFHIR
   • can also be lowered down (and in case you need you can put there #if ...
   • Other option is to raise the major to v2 (with iOS17) and v1 set back to iOS15 with one more minor release with ResearchKit fork v3.

Additional context

It is very unusual for libraries to skip two generations in one minor release and I've never seen that before. By doing this users with iPhone 6,7,8,X, first gen SE, and several models of iPads were cut off and yet I think that there should be a way of gradually updating the minimum supported OS by raising the major number.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct and Contributing Guidelines

[PSchmiedmayer]

@luppoalberto111 Thank you for the issue and raising the concern; sorry about the inconvenience.

Tagging a 1.4.0 with such a breaking change was an error. You are correct in pointing out that this is a breaking change and should be a major version jump.

The jump to iOS 17 was deliberate. We aim to extend out SwiftUI target in ResearchKit (RK) with additional functionality and will rely on iOS 17+ APIs including Observability and others that are not backward compatible. RK 3.0 was a good opportunity to combine this with a iOS 17 bump and to be in-sync with the Apple releases. As far as I can see this was correctly identified and tagged as a breaking change.

We will carry these things over to ResearchKitOnFHIR (RKoF) and while it would be great to support older iOS version in the future we currently don't have the capacity to put too many resources in back-porting elements in the future. Maintaining the RK fork and RKoF is not backed by any funding or support; as is most of our open-source work.

Thanks for pointing out the mistake about the breaking change in RKoF. I have corrected RKoF by removing 1.4.0 and tagging a correct 2.0 with the breaking 3.0 RK changes and the bump to iOS 17; sorry about that!

In summary: It's great to hear that RKoF is used beyond our Stanford Spezi projects and Stanford research, and it is encouraging to hear based on the current state of RK and the time, efforts, and resources it takes us to maintain this package and RK fork-based to support the Swift Package Manager.