[keltex]

I've been playing around with Swift and SwiftUI for the past few months and the thing that baffles me is why are certain features only available with a minimum iOS version.

For example async required iOS 15.0. Why is this tied to the OS? Why can't they include newer runtimes be downloadable like Node / Java / .NET etc?

Other examples are from SwiftUI. For example the NavigationStack appears much more useful than the older NavigationView but that requires iOS 16. Which means that you can't support anything older than an iPhone X.

[e28eta]

Here’s a blog post where they describe the rationale behind switching from app-specific swift versions to bundling it with the OS.

https://www.swift.org/blog/abi-stability-and-apple/

[macintosh-hd]

I think it comes down to Apple trying to avoid as much fragmentation as possible. Fragmentation makes debugging, troubleshooting, and development a nightmare. It’s not an objective good but everything has its trade offs.

[saurik]

FWIW, as the application developer, it increases fragmentation, as more of the code in your app is determined by what version of the OS the user is running. If Apple were developing and debugging everyone's apps, that argument would make sense (but, of course, they are not). If you truly want to minimize costs for development and debugging by minimizing fragmentation you want to provide the most uniform and stable interface as possible for the developer and let the app then operate as identically as possible across every device it will ever work on, not just today but into the future.

[vlovich123]

Most Apple users always run the latest iOS version. And the vast majority of apps aren’t seeing major new OS features each iOS release anymore that they just have to adopt to stay competitive - they can focus on their business these days.

So in that kind of market, this approach does reduce support costs because you just pick a target iOS version to support and test with devices running that and you know newer devices will also just work.

[withinboredom]

> Most Apple users always run the latest iOS version.

I assume you're talking about the latest iOS version for their device, which may or may not be the latest iOS version released by Apple. I was running around with an iPhone 5 until 2019ish when apps stopped working altogether.

[tmpX7dMeXU]

New iOS version adoption figures speak for themselves. Honestly it doesn’t sound like you are “most people”.

[withinboredom]

I mean, looking at https://www.statista.com/statistics/565270/apple-devices-ios... -- "earlier" versions stick around 5-10%, which was enough to keep people supporting IE for over a decade beyond its EOL. So, I don't think you have a valid argument.

[circuit10]

I’m currently on an iPhone 7 so I’m also stuck on an old version

It works fine so I don’t see a need to get a new phone, except less and less apps are going to continue to work eventually

[SkiFire13]

I don't see how this would reduce support costs compared to shipping the runtime with the app. Couldn't you just pick a target iOS/Swift runtime version and support that even if the runtime wasn't tied to the iOS version?

[vlovich123]

The reduced support costs are that your testing complexity (ie cost) is hugely driven by how many OSes you are supporting. By bundling it with the app, you’re pretending that the Swift runtime is the only thing you have to test when you have to test all the OS integration bits. So by tying the runtime to the OS it’s saying “these are the same” and you only have a single compat flag to select. They do this with C++ runtime as well btw. And I believe the language and the runtime are decoupled from what I read although I haven’t paid attention to swift for a long time (ie you can enable new language features without using a new runtime).

The other support costs it reduces is for Apple because their testing matrix for making runtime releases is drastically reduced. Which means the swift team runs more efficiently.

It’s annoying but for end users it’s even more valuable because apps are smaller (and more longevity for storage) and less memory is used.

TLDR: Apple has always run the languages this way and it works nicely for their ecosystem.

[clawoo]

Joke's on them because debugging is already a nightmare.

I've been using Swift since its inception, it's been years since I've been able to pause execution at a certain breakpoint and do "po object" and get something back that is not an error.

[newZWhoDis]

Well for starters, if you were actually playing around with async/await on iOS you’d quickly find out it was back ported to iOS13.

It is frustrating though, although in my case 40% of my DAU are already on iOS 17 (>3m devices) so it’s not the end of the world.

[saled]

My understanding for the reasoning behind this is that they don't want apps to have to ship the runtime stuff to avoid downloads and app sizes getting large.

That could be fixed by just shipping an updated shared library to all phones similar to how Google play services works on Android, but I guess they figure if you're updating anyway you might as well just update the whole OS.

[wahnfrieden]

ASync has been backported to 13

[eviks]

Yeah, that's a bad design that leaves many functional old devices in the dust