New 1.1 operators like .share() won't be available on older Apple platforms (eg: iOS <18)

[stefanomondino]

I was watching closely for months the development of the new .share() operator that just got merged because our apps are lacking an effective way to "mimic" Combine's Publishers (like exposing a "stream" variable that can be consumed in multiple places of the app).

However, I didn't fully realized at first that this operator (and more generally speaking, every new one that will be released as 1.1) will have a very strict requirement of iOS 18.0+ (and same for tvOS, macOS, etc - OS versions from 2024).

This is blocking us from adopting it in all of our apps - it's common to support current OS minus 2 as business requirement for new apps and - as I'm writing - this means a min version of iOS 16.0 (iOS 26 will be officially released next week). And this applies only to new apps, because for already existing one it's really unlikely to drop support to older devices unless really needed (and proven).

The adoption of .share() is important, because it's preventing a proper use of custom sequences in large scale architectures (if I'm exposing a sequence with a variable I get no formal guarantee that some other Task is consuming it). And @phausler already stated the same in the share pitch + the massive work on the implementation - that's actually where I've learned a lot of things on this subject.

I'd like to better understand how we developers are supposed to proceed in these cases, because for at least a couple of years we won't be able to adopt these new features. The alternatives I see:

1. we stick to Combine -> Not 100% compatible with strict concurrency, and the point of it all is to get rid of it.
2. the implementations get backported to older versions as well, by creating custom alternatives to those methods (example: share operatore uses heavily .withLock from Mutex, which is probably the reason why it's getting constrained to iOS 18. One could add a conditional compilation that uses... something else on older Apple platforms instead).
3. we implement custom solutions in our projects to allow share/broadcast/whatever we need -> risky, but seems the only viable solution without interventions from the official repo maintainers.

here we had a brief discussion with @phausler about it but I don't understand how Swift 6.2 is involved compared to os version.

Also it's not clear to me how new features will be added to this repository - is it 1.1 entirely going to be iOS 18+ compatible? With the new availability macros I'm a little bit lost. Will it be possible to mark a new feature as 1.0 available even after 1.1 is out?

Last but not least, please note that I'm writing this GH issue not as a criticism or pretending that I have smart solutions that you didn't think of, but because I think that the community of developers is struggling with many questions on this topic and answers that are not so obvious.

Thanks a lot!

[phausler]

So the locking itself could be transitioned to ManagedCriticalState, but the key parts that were problems for deploying any earlier than the specified releases are things like SendableMetatype which are not available any earlier as well as withTaskPriorityEscalationHandler and additionally a crasher that was around isolated parameters when using older compilers. Those factors are limiting to the implementation (some I have workarounds to deploy further back).

[stefanomondino]

Thanks @phausler - I really appreciate you taking the time to reply, I imagine you went over this countless time already and I'm the nth person you are patiently answering to.

I guess the safest thing to do at the moment is waiting for final release of 1.1 and see how it evolves.

Up to you (of course!😂) whether to keep this issue opened for visibility or not. I guess I won't be the only one struggling with this.