Thanks for this, but I think the main concern from the other thread was the situation of a hypothetical Swift 6 App wanting to deploy to an OS with built-in Swift 5 libraries.
As well as saying that we won't have to bundle the Swift libraries with Apps any more, there doesn't seem to be a clear statement that using cutting-edge language features may restrict deployment options in the future.
I assume Apple will make some kind of reasonable effort to back-port what they can (as happened with ARC), but we don't know for sure. It's really a policy issue for Apple to address with their developer community (rather than a Swift project issue), but lots of people here deploy to Apple platforms so they'd like to know what this will mean in practice.
In practice, I think the availability of language features for "backwards deployment" depends on whether those features can be built on the runtime support that is available — or could be made available retroactively with reasonable confidence and effort. Further, not all language features require additional runtime hooks. In the case where they did, creative solutions may arise — such as the one you mention for Objective-C ARC — that depend on the importance of the feature to users and the difficulty/feasibility of retrofitting the needed runtime support. In some cases retrofitting the runtime support may be quite doable, and other cases it won't be.
It will really come down to the concrete cases that we will encounter in the future. Generally speaking everyone recognizes that most app developers don't raise their minimum deployment target for their apps to always match the latest OS release, and language features that depend on runtime availability could lag in adoption (which is not great) if they are gated on what OS the app is running on.
All of us involved with Swift want to make it successful and a real asset to the developers who use it, and we will continue to explore technical approaches to evolving the language that maximum its impact on its users. I know that's a vague statement, but ultimately the "reasonable effort to back-port" and other possible options all are derived from that intent. To be clear that's not a promise that all language features can or will be backported to work with earlier runtimes; it's just a recognition that it is an important thing to always consider as the language evolves.
I think we've been pretty clear about that. If you build an app with a minimum deployment target of iOS 11 or 12, it will be bundled with the Swift 5 library. If that app happens to find itself running on iOS 12.2 or later, it will use the OS library over the bundled library, and the App Store will take advantage of that to "thin" the bundled library out of downloads to such OSes. But it will run on any OS that's at least the OS you set as the minimum deployment target.
If Swift 5 apps couldn't deploy backwards or forwards, we, er, would never have taken the technical approach that imposed that constraint because it'd be totally unacceptable.
Yes, that should be fine too! In that case, the Objective-C layer serves as your interface layer, and the Swift parts that have ABI concerns (the parts that interact with the Swift runtime) will be set.
Many thanks for the post! Two questions about Library Evolution:
This happens when Apple updates the libraries in an OS, but it’s also important when one company’s binary framework depends on another company’s binary framework. In this case, updating the first framework would ideally not require recompiling the second framework.
Shouldn't the last sentence be the other way round? If I read it correctly, the first framework is the client so ideally there should not be a need to recompile the first framework (the client) if the second framework changes.
And the second question: Can ABI stability be considered as implementation of Library Evolution, but limited to Swift Standard Library only?
Oops, you're exactly right about the quote. My bad. I'll fix it later today.
As for your second question, ABI stability doesn't actually cover Library Evolution for the standard library. As noted in that table, on its own it only lets you change the compiler, not the standard library implementation underneath it. For Apple's "Swift in the OS" story, we've implemented enough of Library Evolution in Swift 5 to use in the standard library already, so that it's forward-compatible in the way we plan any "resilient" library to eventually be.
I'd like to do the same for a project, but how would you do that? As soon as I add a swift file to my Objective-C framework and build, a .swiftmodule file is added to the Modules folder in the built target.
Hm. I hadn't thought about this, but I guess you could manually delete the swiftmodule out of the Modules folder as a Run Script build phase. Can you file a Radar to suggest that this be added as a build setting? (It'll be less relevant when module stability is done, I guess, but not totally unreasonable.)