Will Swift Concurrency deploy back to older OSs?

no.

Denial -> anger -> bargaining -> depression -> acceptance
                       ^
                      now
55 Likes

Sure, but sometimes older releases needs to be put in maintenance mode for that 1% and customers who upgrade get newer features. Itā€™s quite common, e g. It is how it works for us when we upgrade the OSā€¦

In response to both: How? This isn't a hobby. As a full time commercial developer trading real work that needs doing now versus learning about new features I can't use in anger for several years you know which is going to win. I've justified the time spent on following concurrency threads as something that was going to be useful this year. Now it's not. And as it seems Swift 6 will change things again why learn about a 5.5 I can't use now - will it get to the point that next years iOS16 will actually be required to use a solid version of concurrency?

As a comparison SwiftUI came out 2 years ago and I had a side project I was able to use it on - not a great experience as the whole framework was very new and undocumented and incomplete in many ways. I certainly would not recommend anyone who wasn't about to use it to spend a serious amount of time on it, then given the changes in iOS14 things changed a lot and improved a little, and I bet they've changed again in 15 so a lot of that previous experience is deprecated. I won't know for a while - that side project is done, and the main project supports older OS so SwiftUI is of no use - I'll find out what the latest way of using it (and Combine) when I get to that OS version as a minimum. [SwiftUI being iOS13 only was much more understandable, even if disappointing, my view was that it was a large proprietary framework built on top of new common language features, so had a good reason for being new only]

The biggest problem with this whole thing IMO is the surprise - I'm not sure what I missed that would have clued me in that this change was going to be so heavily bound to a new runtime. Maybe that's my naivety and/or lack of low level runtime knowledge, but from the volume of posts here it seems I wasn't the only one.

8 Likes

I've started a petition for a backport - please sign it to help push it along inside Apple.

2 Likes

No, it is not just app bundle size ā€“ unless what you mean is shipping the OS with your app. Because the OS itself is written in the same language, you would need to ship the entire stack beneath you. Not just MapKit, but MapKit, UIKit, CoreGraphics, QuartzCore, libSystem and even the kernel. But even if this were possible (and I think you realize you canā€™t bundle the kernel), it is still not a matter of just binary size, though obviously at this point that is enough to say of course this approach is not viable. Updates to these components must happen independent of users updating their apps. Only this way can the OS gain new features or fix bugs without app developers recompiling their apps and users redownloading them.

15 Likes

I'm trying to be constructive. Here's the fact:

On iOS 14 / Big Sur, these languages supports async/await:

  • Rust
  • JavaScript (React Native or JavaScriptCore or WebKit)
  • Dart (Flutter)
  • Kotlin native
  • C# (Xamarin)

But we need iOS 15 to use async/await. This makes much less persuasive to even try concurrency of Swift this or next year. Because the leadership of most team would think engineers like:

if all you have is a hammer, everything looks like a nail.

Steve Jobs also said similar things like:

You can't start with the technology and try to figure out where you're going to sell it.

We cannot start with Swift concurrency and abandon users with early iOS versions.

Whatever technology we choose, our users are eventually to be served.

For Apple, it's an easy decision because iOS 15 / macOS 12 are the incoming major version to be maintained.

I believe most people in this thread are hoping to deliver robust code to serve our users, making them happy right?

I wonder if the community comes up with an idea or solution to bundle the Concurrency part as a binary (like xcframework), would Apple reject it?

1 Like

I do admire the passion. Though I think this sentence sums it up pretty well:

13 Likes

I agree that part of my effort in following and understanding the concurrency discussion (and contributing where I could) was related to the fact that I was expecting this feature to impact my work sooner rather than later, and I think that the emotional impact that this announcement had on a large part of the community shows how much we care about the language: I love promoting Swift with my colleagues, I believe in a great future for it, and I always try to push the boundaries of the language and use its features in full in my daily work.

I hope that the core team acknowledged and expected, while working on concurrency, that this limitation would have been terrible news for many Swift developers, that basically feel betrayed (in some sense I feel too). I also understand that this is not related to Swift per se, but to the platforms we're developing on, that (sadly) are not open-source and follow different development cycles than Swift. But the fact that Swift is so awesome and open-source made us forget that many limitations that we face are related to the specifics of Apple platforms, that as any platform have good parts and bad parts in terms of developer experience.

I guess that if this specific limitation was clear from the very start of the concurrency works there wouldn't have been such negative emotional (but also pragmatic) response from the community. But the response would have been negative nonetheless, because it would have reminded us that Swift development and evolution is an amazing thing, but it's in practice "wrapped" by layers of platform limitations that we need to deal with, and it feels like there's huge distance between the awesomeness of Swift evolution (and the huge efforts made by the core team), and the general state of Apple platforms.

Swift concurrency seems to be the case, up to this point, where this distance stroke the hardest. The comparison with what happens with Kotlin and Android, while technically irrelevant (Kotlin has nothing to do with Swift), are on point in terms of developer experience. While dropping iOS 12 support is probably going to be feasible for many developers next year (not all developers, unfortunately), unless Apple "forces" users - with compatible devices - to update to iOS 15 when it comes out, many developers will simply be unable to use these features for years, which means library authors won't be too, which means that we're simply not going to test Swift concurrency in a sufficient number of real world scenarios, which in turn would delay the real world feedback needed for the next steps (Swift 6 and beyond). And this will also impact Swift development and evolution, and will always do if future features will be locked to the very latest OS version.

I'm realizing that I should probably thank Apple to have made iOS 15 compatible with all iOS 13 and 14 compatible devices: it that weren't the case, this would really have been a major disaster.

5 Likes

Hey Doug,

Thanks for laying out those points. I don't want to sound argumentantive (I don't deny the existence of these trade-offs), but I think it's necessary to reflect on the question: Are these the right sets of trade offs? Do we think they are worth their consequences?

I have a gut feeling that devs are so allergic to this exhausting cycle of not being able to use language features because of OS restrictions that they (and their users) would gladly accept:

  1. VMs, and the small performance hit there
  2. multiple runtime frameworks and the space that takes (if their management was transparent and easy), if it meant their apps work and their phones donā€™t become e-waste
  3. Actors/concurrency that isnā€™t deeply kernel integrated (which is what weā€™re already doing, anyway)

ā€¦If it were in the service of alleviating this repetitive cycle of frustration.

I would cite React Native as the case-in-point. Though Iā€™m not a big fan of it, for unrelated reasons, my company has widely adopted it, in part because of how well it insulates devs from these draining frustrations.

The desugaring approach is also really appealing. If async functions were available today as a desugaring for completion handlers on older OSes (which is what weā€™re already doing, with all the heap allocations, indirections, and so on), and naturally became more performant as adoption of newer OSes spread, then that seems like a good trade off, if itā€™s possible.

2 Likes

I think @mycroftcanner meant that he was okay to drop support for iOS 14 and just focus on iOS 15 for a new app. However anyone with iOS 14 who would see an App Clip would expect the app clip to work for that version.

1 Like

This point keeps coming up, but it seems... misguided at best? As has also been mentioned several times, iOS hasn't dropped support for any devices since iOS 13ā€”I feel like it's clear that device longevity is something Apple has been actively optimizing for, so I don't think it makes sense to suggest that restricting concurrency to iOS 15 was somehow motivated by a desire to get users to buy new devices (and veers towards assuming ulterior motives on behalf of the core team).

8 Likes

I had MacOS in mind, where device life cycles are expected to be much longer.

I don't want to accuse anyone of malicious motives, but regardless of motives, this is what's happening.

Unless there's a patcher, my 2013 iMac, which is still plenty powerful (3.5 GHz quad core, 32 GB of RAM, 4 GB VRAM, PCIe SSD, etc.). will stop getting third party software updates. This computer will continue to serve me for at least another 5 years, probably 10... under Windows or Linux. Because somehow, those have better backwards support for macs than _mac_OS (:exploding_head:).

I don't think it's unreasonable to expect 10+ years of useful life out of a five thousand dollar computer.

7 Likes

Instead of putting effort into backporting, maybe some refactoring tools could be provided, so that devs can use this and next year to prepare their code-bases in a way that makes it easier to finally switch to the new concurrency world when enough of their users are on iOS15.
Can we prepare somehow for an actor world? Can we already add Sendable to our types? Etc.

1 Like

I find it interesting how many of the posts here seem to be implying that there will be no support for Swift concurrency on older operating systems, perhaps resulting from policy decision or because of some technical defect of Apple's operating systems, when the only official word we have implies the exact opposite - that there will likely be some kind of support.

I mean, if it was completely out of the question for any technical/non-technical reasons, I expect the core team's messages would have said that. But they don't - they acknowledge the value of "back-porting" and say the team will be exploring it. I'm sure none of us would suggest that they are giving false hope or lying, so clearly they see some genuine reasons to be hopeful that at least some of the concurrency features will be supported.

There is some precedent for back-porting major developer features: see arclite, which allowed developers to make use of automatic reference counting in Objective-C while deploying to older OSes, but it couldn't support some features (e.g. auto-zeroing weak references) which required more invasive changes to the Obj-C runtime. My guess is that back-ported Swift concurrency will look something similar to that; support for some things, but not everything. At least, that's my guess, and it seems to be consistent with the core team's messaging so far :man_shrugging:

That's why I suggested (not demanded) some discussion of the technical challenges, as a means to dispel the idea that this is solely a policy decision, and to show the community that thought is being given to addressing specific issues and supporting as much as is practical. Evidently, many developers don't perceive that at the moment, and I think changing that perception would be valuable. IMO, there seems to be a communication problem here.

12 Likes

I actually find continuing this thread to be extremely counter-productive. Apple has given a clear answer to the opening question. At this point the thread can only serve as distraction from the work necessary to actually accomplish the goal.

48 Likes

@anandabits I strongly disagree!

There is a difference between knowing things and understanding things.

While you may be happy living in a world in which we are instructed knowledge. Some of us like to questions things and get to the bottom of things.

"Knowledge cannot be instructed by a teacher, it can only be constructed by a learner"

That makes perfect sense when it is productive. In this case my point is that it is counter-productive. There is little the community can do to help. Any time Apple employees spend explaining the issues is time they are not spending working through them.

11 Likes

Perhaps. Thereā€™s also the danger of leaving a perception that Apple didnā€™t want to do these things until developers pressured and petitioned them in to it. That wouldnā€™t be good for Swift, especially since this is unlikely to the last time new language features wonā€™t be deployable to older OSes.

1 Like

What frustrates users is when the decision to drop support seems completely arbitrary. For example the technical specs of my old high end iMac late 2013 are nearly identical to an early 2014 model and yet I can't run Big Sur on it. Yet, if I patch the boot loader (without touching the operating system, Big Sur and Monterey runs perfectly on it and much faster than on the lower spec'd supported hardware.

1 Like