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.
I'm trying to be constructive. Here's the fact:
On iOS 14 / Big Sur, these languages supports async/await:
- 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?
I do admire the passion. Though I think this sentence sums it up pretty well:
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.
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:
- VMs, and the small performance hit there
- 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
- 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.
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.
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).
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 ().
I don't think it's unreasonable to expect 10+ years of useful life out of a five thousand dollar computer.
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.
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
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.
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.
@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.
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.
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.
Let’s avoid going too deep down the rabbit hole of discussing whether this thread itself should continue. It’s too meta. The mods can decide that for themselves, without members telling them which threads should/should not continue.
Despite the harsh tone in this thread, it is the reality of the situation. Apple wants developers excited to create apps for their platform, especially this week with WWDC going on.
A couple years ago when SwiftUI came out and had the iOS13 requirement, many of us groaned. It looked like amazing technology but we knew it would have to wait. Now, the same thing is happening with the next paradigm shift of Swift. We are constantly having new tech dangled in front of us on a stick, and it's frustrating not being able to reach out and grab it. Rather than being excited this week for WWDC I find myself not wanting to watch most of it.
This isn't a new problem though, any old-timer Android developer remembers much of the same happening with Google, like finally getting Java8 support and the Android Support Library. I'm sure we can find a similar path forward on iOS.
Anyway, I do appreciate the Apple engineers responding throughout this thread and making us feel heard. The frustration here is from us wanting to use your tech very badly, which is a good problem to have.
Personally, I agree. For me, it's emotionally painful to see such negativity from the community after working hard to help make Swift Concurrency happen. I'm surprised to see people injecting ulterior motives into the discussion, making wild suggestions to the Swift team to rewrite or reimplement the whole feature (or the entire system stack), and starting a petition, all because Swift concurrency isn't compatible with their project's minimum deployment target right now.
OK I'm locking this thread now, because the majority of new posts are off-topic or inappropriate and getting flagged, and I really don't want to mess with people's trust ratings by approving/rejecting them. As Doug and Ted have said, we hear everyone who is enthusiastic to adopt the new features loud and clear, and we'll keep you updated on our findings as we progress.
For those interested in the technical implementation challenges, I recommend posting focused questions to the Compiler Development topic – but please be understanding about the time it takes to produce responses explaining these details.