Will Swift Concurrency deploy back to older OSs? Flame
By - zboralski
Correct. The real WWDC experience is just labs for a week and then watch videos months later
Apple NEEDS to stop shipping stuff as part of the OS afaik.
You can update Chrome on Android without updating the entire OS.
Safari on iOS? Nah. Gotta update the entire OS. When you can’t, buy a new phone. Ridiculous tbh.
There is no reason the “AppStore” itself couldn’t have updates for Swift Runtime or allow developers to distribute the apps with a specific runtime like the CRT and when updating an app it installs that new runtime automatically or prompts the user to install it. Only things like security patches and new OS UIs (notifications widgets, etc) should require OS updates.
Users never have to install a new windows version to update an application. They just update .NET or the application itself which ships with a newer CRT or compiled with a newer compiler. Whether libstdc++ or libc++ is statically linked or not, it’s up to the devs.
Even Xcode requiring a new OS version is weird and on top of that the device needs a new OS too lol. It’s a joke at this point.
Those devs are right. No one would use it for the next 3+ years as you can’t just drop backwards compatibility and you can’t if-available every single asynchronous function to mark it async and await on it.
I don’t think iOS needs a “support library” like Android, but it’s in need of something.
> Gotta update the entire OS. When you can’t, buy a new phone. Ridiculous tbh.
To be fair, the Phone 6S (six years old) will get iOS 15.
Yes but just because a 6 year old phone gets the update, it doesn’t mean the owner of that phone will update.
With our app, a sizable chunk of our user base is on older versions of the OS, but are using phones capable of updating to the latest OS.
I consider myself very lucky that our product owner is willing to let us bump our minimum version number. But we have to coordinate and provide support articles to tell users how to update their phone if they suddenly can’t use the app.
Not everyone has the luxury I do.
It should really be on Apple to start making things backwards compatible. Or at least make phone updates more aggressive.
I have autoupdate turned on, but I often won’t get updates unless I go into settings and tell it to update.
I don't know why OS runtime updates might / might not be practical, but as for bundling the runtime with apps, the Swift blog post [Evolving Swift On Apple Platforms After ABI Stability](https://swift.org/blog/abi-stability-and-apple/) says the following:
> **Can I choose to bundle a newer Swift runtime with my apps going forward to be able to use new runtime features without requiring a new OS?**
> This will not be possible for a number of reasons:
> - The coexistence functionality that is used to maintain compatibility with pre-stable Swift runtimes depends on there being no more than two Swift runtimes active in a single process, and that all Swift code using the pre-stable runtime is self-contained as part of the app. If the same mechanism were used to allow a newer Swift runtime to be bundled to run alongside the OS Swift runtime, the new runtime would have no access to Swift libraries in the OS or ABI-stable third-party Swift libraries linked against the OS runtime.
> - Outright replacing the OS runtime with a bundled runtime would circumvent the security of the system libraries, which are code-signed based on their using the OS version of the runtime.
> - Furthermore, if the OS Swift runtime could be replaced, this would add a dimension to the matrix of configurations that the OS, Swift runtime, and third-party libraries and apps all have to be tested against. “DLL hell” situations like this make testing, qualifying, and delivering code more difficult and expensive.
> - By being in the OS, the Swift runtime libraries can be tightly integrated with other components of the OS, particularly the Objective-C runtime and Foundation framework. The OS runtime libraries can also be incorporated into the dyld shared cache so that they have minimal memory and load time overhead compared to dylibs outside the shared cache. Eventually, it may be impossible for a runtime built outside the OS to fully replicate the behavior of the OS runtime, or doing so may come with significant performance costs when constrained to using stable API.
For the specific case of concurrency, Ted Kremenek also [says](https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370/77) that it needs new primitives in GCD and the kernel.
I’ve answered this question already: https://reddit.com/r/apple/comments/a4bthx/_/ebdoqxf/?context=1
tl;dr: Apple OS split apps and frameworks such that there is no versioning as they are built as a cohesive whole. They don’t do minimum version checks. They aren’t built to be backwards compatible. The sheer amount of testing that goes into each release is because no one wants a buggy OS to begin with. Therefore it is an anti-pattern to separate app updates from the OS when the apps are a part of the OS.
Great idea, let’s make iOS like Windows /s
That’s not the point. Modularity is. iOS & macOS is BSD based and there’s absolutely no reason to require a whole new OS for concurrency. A whole new OS for a language feature. A whole new macOS for an IDE (Xcode). Linus Torvalds would lose his shit hearing this.
Well, if the OS is written in Swift, yes it would be tied to the language version.
Remember - the system libraries are part of the OS. Imagine async/await that was fully integrated with the OS’ I/O Subsystem so the kernel knew exactly which tasks were waiting for which files and how everything fit together, without clunky APIs like DispatchIO - just a simple “await loadFile(path)”. It could handle intelligent streaming, backpressure, and a lot more by being integrated with the system.
Linus Torvalds loses his shit about a lot of things. I wouldn’t presume to know what he thinks about any particular issue; he has a lot of experience which means his opinion might not be what you naively assume it would be.
The OS isn’t written in Swift though. iOS existed long before Swift was a thing and it hasn’t been written from the ground up. IOUSBFamily is still written in Objective-C++ for example.
WebKit is Objective-C++ too. The kernel is BSD based and isn’t written in Swift or Objective-C. It’s C.
Most of the system libraries are Objective-C & Objective-C++. You can see this when you jailbreak and view them in Filza or ssh into the device and view them. I haven't seen a single one using Swift Runtime. iOS 13 is when they started bundling Swift into the OS. https://github.com/xybp888/iOS-SDKs/tree/master/iPhoneOS13.0.sdk is the first SDK when we start seeing `swiftmodule`
Fair enough on what Linus thinks. You’re right I don’t know what he thinks.
The OS is more than just the kernel and drivers. Frameworks like SwiftUI and Combine are part of the OS, as is Foundation (parts of which are written in C, but some parts are written in Swift). Network.framework’s C API is so awkward it certainly looks like a wrapper over Swift. There will certainly be more Swift in the future - after all, it was created to be a memory-safe alternative to C and a faster alternative to Obj-C. Also, some of the bundled applications were created in Swift before iOS13 - e.g. the macOS Dock, the new music and weather apps are confirmed to use SwiftUI, iOS’ springboard is probably Swift, etc. It’s not easy to tell by looking at the SDK just how pervasively it is used by the OS. Also, the concurrency features are very, very new (literally still going through swift-evolution), so don’t be surprised if Apple explores deeper integration in, say, Foundation async APIs in minor point updates.
I expect that WebKit will begin transitioning at least some components to Swift in the near future. Safety issues with C are what motivated Mozilla to create Rust, and similar motivation should apply to WebKit.
Very detailed :) +1
Yes the bundled stuff was before iOS 13. But after 13, most people changed to the built in OS RT.
Prior to that though, none of the core frameworks and kernel was written in Swift afaik. I’ve ran quite a bit of them through HopperDisassembler when making jailbreak tweaks. That included CoreNFC, CarPlay, Foundation and a few others. I don’t remember seeing any part of Foundation being in Swift. Maybe it changed after iOS 13 which is when it became part of the OS.
Of course it can be still used in the OS just as Dot Net frameworks are used for Powershell and other components.
It’s the tight coupling of language features that is angering developers. Combine requiring iOS 13 for promises and futures when PromiseKit and Google Promises worked just fine before. Concurrency now requiring iOS 15 when there are async await libraries already working prior to that like AwaitKit.
I get that SOME of it requires OS changes but surely not all of it. Even if it were a subset of it that was backwards compatible people would be fine with it.
The coupling is what is bad not just for iOS, but bad for Swift. I don’t see why the language feature requires such deep integration with the OS. C++‘s standard library never requires that you update your OS to use C++11, 14, 17, 20, etc.
OS features are 100% understandable. Notifications is what I listed previously for example. It’s understandable this would require OS support as it needs to work on the lock screen and so on. But language features I have a problem with. Especially when it happens every update.
Also, thanks for being civil and discussing such topics! :)
I say this AND I say the same for MacOS. I can't install the latest Xcode without updating MacOS.
I just don't see that MacOS needs to be updated and it's not an issue of what it offers being any better, I just don't care about the OS, I care about Xcode because I want to upgrade Swift.
Seriously, I hate this. The way Apple prevent you from developing software on anything but the latest Xcode, which in turn always needs the latest OS version, is a terrible habit that needs to change.
Seems to be some policy thing because you can't tell me that I have to have the latest Xcode in order to run the latest Swift, it's complete BS. I could see one of the upgrades that required you go to metal but past that why exactly do you need the latest Xcode to run the latest Swift they're two different things.
> There is no reason the “AppStore” itself couldn’t have updates for Swift Runtime or allow developers to distribute the apps with a specific runtime
You absolutely do not know what you're talking about...
Why don’t you explain then. At one point the Swift Runtime was bundled with applications and not part of the OS at all. That was changed later down the line: https://swift.org/blog/abi-stability-and-apple/
You seem to know what you’re talking about absolutely….
Do you not realize that you posted the link explaining answer to your question? I assume you didn't bother to read it?
Do you not realize that link I posted is also explaining why it could be done (as it was in the beginning)? Guess you didn’t bother to read it.
Again: it was that way in the past where it could be bundled. There is no reason it couldn’t go back to being that way OR have the AppStore itself install it when installing applications. Swift 1 to 4 didn’t have it in the OS and it was bundled with applications.
Again: if .NET and the CRT can do it, it can be done here too.
Saying I didn’t read it or I don’t know what I’m talking about without any explanations is stupid. Not sure why I bother wasting time explaining to a low effort supposedly know it all poster.
SwiftUI not being backported is awful, iOS 13's implementation is riddled with bugs and every point release (on 13 and 14) have app breaking bugs that need specific fixes only relevant to that version.
After that I'm surprised Apple hasn't learned a little bit of their lesson here. This is insulting to the developers who work on their platforms. No effort in long term thinking at all.
Ran into an issue we couldn’t reproduce but our client could, turns out he was one point release of iOS 14 behind us. We got a device with the same version and the bug was related to SwiftUI and updating was the easiest fix ….
SwiftUI is simultaneously amazingly cool and the biggest Apple clusterfuck since iOS - and it hasn’t even been acknowledged by them
New technologies often are.
It’s safest to avoid any new apple technology for at least one and probably two releases. I can’t think of one that wasn’t a shitshow on launch. Xcode still is decades later.
Yea we ran into the same issues on iOS 13.
I can’t believe how much better swiftUI works going from 13.7 to 14.0.
Apple REALLY needs to backport the fixes at the very least.
We had to bump our minimum version from 13.0 to 13.3 because 13.0 had swiftUI crashes left and right that made our app completely unusable. That being said, it’s almost flawless on iOS 14.
There are quite a few gotchas, but they are more “learn2SwiftUI” issues than problems with the framework.
yep, we're at 13.7 now, at which point we should just do 14 but can't because customers want iOS 13 support
thats part of the plan for SwiftUI in the first 3 or 4 years (like Swift itself)
This is actually good for SwiftUI long term, it wont have tech debt, making deprecation and re-engineering much easier (its always hard to engineer something perfectly the first time, and having to stick with that early choice is very damaging long term.
Huh? For the first 3-4 years of Swift, it was bundled with Apps. SwiftUI was never bundled with Apps; it's a system library. It has been part of the OS and guaranteeing a stable ABI since day 1.
What you're saying about making deprecation easier? That's if you \*don't\* have a stable ABI. SwiftUI in 3 or 4 years will still need to support Apps written and compiled for SwiftUI 1.0 from iOS 13.
Afaik, the new async/await syntax in swift 5.5 is available on iOS 14, just not any of the new apple APIs that use them. So you can make your own code using it, just not things like the new URLSession methods, as long as you build with Xcode 13
I don’t think that’s quite right. See [this post from Ted](https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370/4)
Yesterday I was able to compile and run swift 5.5 code on iOS 14.4 using Xcode 13, so maybe he means just Apples APIs
You can compile the code, but there’s no way to call that code. The “async” global function requires minimum OS support.