Is there a supported OS policy?

[devioustree]

Naturally the Package.swift will contain the currently supported OSes but is there a policy about how long an OS version will be supported, or how many major releases would be supported? Alternatively, what factors would go into the decision to drop support for an OS?

Related: is it likely that the watchOS and iOS versions will be be kept in sync?

[mbrandonw]

Hi @devioustree, we don't have any "official" policy, but also not sure what an "official" policy looks like. Do you have any precedent of other projects that have something similar?

Our own personal view is that we try our hardest to maintain backwards compatibility with older OS's. In fact, the library was first released 3.5 years ago, and we still support the same platforms we did back then. And we have upcoming work on introducing Swift's new Observation framework to the library, and we will do so in a way that still keeps those some platform requirements. Currently we have no plans to drop any platforms anytime soon.

Related: is it likely that the watchOS and iOS versions will be be kept in sync?

I'm not sure what you mean by this. Can you explain a bit more?

[devioustree]

Thanks for the speedy reply. I definitely appreciate the level of effort you expend to maintain backwards compatibility. This request is primarily concerned with helping me sell TCA by evaluating the risks of adopting an external dependency for a critical piece of infrastructure - essentially being able to easily demonstrate the effort you do to other stakeholders.

I don't have any examples to hand from other projects, but I can take a look.

Things that can come up as part of the evaluation:

• is there a minimum supported OS policy e.g.
• would deprecating an OS require a a major version bump?
• would security or critical bug fixes be applied to the last supported train?

Related: is it likely that the watchOS and iOS versions will be be kept in sync?

I'm not sure what you mean by this. Can you explain a bit more?

Sorry for the lack of clarity. The intended question is: will the supported OS generations be kept in sync e.g. if watchOS 6 is deprecated then iOS 13 is also deprecated? Through experience it's been a challenge to support apps that deploy to different watch and phone platform generations, although it can be beneficial for users.

[mbrandonw]

I don't have any examples to hand from other projects, but I can take a look.

Just so that we understand, does this mean your project does not currently use any 3rd party dependencies?

is there a minimum supported OS policy e.g.would deprecating an OS require a a major version bump?would security or critical bug fixes be applied to the last supported train?

Again there's nothing "official" here because I'm not sure what "official" looks like concretely, but I can shed light on how we personally think about each of these points:

• We currently support versions of OS that are now over 4 years old and really have no need to change that anytime soon. Because we view TCA as a light layer on top of Apple's platforms it's quite easy to still target old platforms. We are simply using the same availability that Apple's tools do. For example, NavigationStack is iOS 16+ and so our NavigationStackStore is iOS 16+. The core of TCA is quite separate from any of Apple's platforms, and hopefully someday soon will be a pure Swift project with none of Apple's proprietary frameworks involved.

  And when we do decide to drop an old platform, it will most likely be one at a time. That means supporting iOS 14+ when and if we decide to drop some platforms.

• Deprecating an old platform would not be a major change, but completely removing an old platform would.

• We did this after the 1.0 release. We had 3 releases to the 0.x after 1.0 was released: 0.58.1, 0.58.2, and 0.59.0. And if there were other things that the community wanted added to 0.x we would happily accept PR's.

The intended question is: will the supported OS generations be kept in sync e.g. if watchOS 6 is deprecated then iOS 13 is also deprecated? Through experience it's been a challenge to support apps that deploy to different watch and phone platform generations, although it can be beneficial for users.

Yes, I don't see why platform versions would ever get out of sync. As I mentioned above, it is not really that hard for us to maintain backwards compatibility with old platforms. We simply omit new tools from the old platforms when necessary.

We don't plan on eliminating support for older OSes anytime soon, but if there is a motivating reason for us to do so in the future, we would announce the intent in advance on these discussion forums, and solicit feedback for the change. In fact, we originally intended for 1.0 to change our minimal support to the iOS 14+ in order to utilize @StateObject, which we communicated during the beta period and found just a little pushback, but that exploration wasn't fruitful enough to commit to, so we kept things as is.

[devioustree]

I don't have any examples to hand from other projects, but I can take a look.

Just so that we understand, does this mean your project does not currently use any 3rd party dependencies?

The risks associated with integrating a project like TCA can be greater than other types of dependencies because of the large surface area it can touch. This means stakeholders might put it under an increased level of scrutiny.

All of your answers have been extremely helpful, thank you 🙏🏻

[mbrandonw]

I just wanted to bring this discussion up again in light of our recent public beta for the new observation tools in the library. While it is a significant addition to the library, we have taken the time to make it 100% backwards compatible with the current 1.x version of the library. And we even back-ported some of Apple's tools so that they work on iOS 13. So, when the final version of the tools release it will be just a minor, 1.x release of the library.

So while we do not have any kind of "official policy", we hope that the library does show our commitment to it being a good citizen in the ecosystem.