For some of Swift 5.1s features I think this has been disclosed already, but is there a list of all (tentative) new features and if they are reliant on the new runtime?
It's a pity to not be able to use some of them for years to come because of the necessity to backdeploy.
FunctionBuilders?, PropertyWrappers?
As far as I understand, function builders don't introduce any runtime or standard library changes, so should be useable with any deployment target as long as you build with Xcode 11. Not sure about property wrappers, I don't have much knowledge of how those are implemented.
Pretty much everything in the language is backwards-deployable besides opaque result types, because as Max points out they compile down to existing constructs.
Pretty much everything in the standard library is not backwards-deployable because it has to exist at run time. A few fixes are set to be emitted into client apps instead of living in the stdlib, but that's not the common case.
Property wrappers are backwards compatible.
@jrose was it not that opaque result types are backwards compatible as long as members returning opaque type are not public so they donāt cross module boundaries?
@Joe_Groff can answer for real, but I believe the answer is still no, at least not without even more care. Offhand, I can think of problems with nested types defined in such a function.
Back deploying internal uses of opaque types would require the compiler to fully optimize away all opaque types to their concrete types. This might be possible. We could theoretically backward deploy the runtime support to older runtimes too, using the compatibility library, but it would require implementation work to do so.
And here lies the downside to an ABI stable, shared standard library. Are macOS minor updates going to push out new standard library versions? Are we just SOL if we want to use new features?
Is there a way to bundle the latest standard library in our apps? I'd rather take the hit in binary size than play into forced obsolesce schemes.
I was just thinking about the mangling of types defined inside functions with opaque result types.
Just to be clear ā does it mean that, if Apple had decided to delay the ABI compatibility for a couple of months (and one point release of Swift), those powerful new runtime features would be available on every OS version where Swift works (iOS 8+, macOS 10.9+)?
These questions have been answered in the blog post "Evolving Swift On Apple Platforms After ABI Stability".
Not completely. Specifically the question of whether a minor OS update would include updated runtimes is not addressed directly in that post, and hasnāt been anywhere else iāve seen. The general avoidance of the topic does, however, point to ānoā.
With the Swift stdlib and runtime as part of the OS, updates happen at Apple's discretion. (That's part of why the @available version numbers for Apple platforms in the open source repo stay at 9999 until Apple releases a public beta that includes those changes.)
Moderation note: please don't use TLAs as a way around using respectful language on the forums.
Had to google that, brilliant!
It's not just about binary size savings. Without binary stability, Apple could not use Swift's types in their own frameworks. That isn't a take it or leave it thing.
Would the current (5.1) runtime technically work on earlier versions of iOS and macOS, where Apple doesnāt use Swift in their frameworks?
Apple does provide swift APIs for the system frameworks starting with iOS 13 and macOS 10.15. I guess that would make it not possible to include a future (say, 5.2) version of Swift runtime in the app as it wonāt be compatible with the system one.
The runtime demangler is one of the components that is hooked for backward deployment, should we have the time to use it.
From Evolving Swift On Apple Platforms After ABI Stability (emphasis mine):
[ā¦] the Swift runtime is now a component of the userās target operating system rather than part of the developerās toolchain. As a consequence, in the future, for a Swift project to adopt new Swift runtime and standard library functionality, it may also have to require new OS versions that include an updated Swift runtime supporting the added features.
Any feature that requires new Swift runtime or standard library support may be subject to OS availability restrictions.
Is it fair to say that these OS availability restrictions are specified through the list of SDKs in Apple's Developer Documentation? For example, the Combine framework lists the following SDKs:
Does this mean that we would need to use the following conditional statement to safely incorporate the Combine framework into an app that we also plan to deploy on older operating systems?
if #available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) {
// Call functions from the Combine framework
}
(Incidentally, I just realized that I don't know how to specify a version for UIKit for Macā¦)
That's correct, just like you would for any new Foundation APIs introduced this year.
(I don't know if we have a final syntax for "UIKit for Mac" yet, but it'll take it from the iOS version if it's the same.)
Greatāthanks for confirming! 
One more thing: is it possible to run an app in Xcode using features that will be released in a future OS? Put another way, does Xcode include its own version of the Swift runtimeāseparate from the underlying OSāfor debugging? So, for example, could we use Xcode 11 on macOS 10.14.5 to build and run an app that uses the Combine framework?