I understand this but what I forget/don't understand is why this can't be tested in a snapshot on 10.14? Can you or someone remind me?
The runtime in snapshots depends on the latest OSes, and cannot be used with Swift frameworks in the OS such as SwiftUI or Combine, because there can only be one active Swift runtime in a process. It can be used to test new runtime or standard library functionality, but isn't designed to be distributed with end-user software.
Does this not include opaque return types? 
Yes, but because snapshots require the latest OS, and can't run concurrently with the OS runtime, they aren't very useful for backward deploying the feature.
1 Like
I've found most of your posts in this thread fairly rude, and these in particular don't seem particularly relevant for the platforms that you're complaining about (if you have reason to believe that they are lying in their reports to the SEC then please contact relevant authorities). I don't know if your posts should have been flagged, but you seem to be using hyperbole to try to elevate a technical decision that you disagree with into a grand moral issue, where not agreeing with you means supporting slavery, warlords, etc. The posts were off-topic, at best, in a discussion about the backwards compatibility of opaque return types.
10 Likes
I'm really pleased to see that SEC report! They should advertise that more, that's a huge win!
And it's really not hyperbole. Unsupported apps make people upgrade sooner than they otherwise need to. If not the humanitarian concern, the environmental concern is still present, and it's important.
2 Likes
It is.
2 Likes
Correct me if I'm wrong.
Why can't we always ship our app with the designated Swift runtime copy which our app is compiled against, and let AppStore help us to decide which copy of runtime to use: when distributing to a platform with old OS versions, the AppStore will not trim off the bundled runtime copy and the app will just use this copy when running; on the other hand, if the app is downloaded on the latest systems, the bundled runtime will be trimmed away, and the one comes with the OS will be used.
As far as I am concerned, I truly hope the great efficiency of using something like "opaque result types" in my developing, won't turn out to be only supporting those functionalities that just a part of my audience have access to.
2 Likes
This worked well, when all swift code shipped with our app, was either written by you, part of the swift standard library, or a framework inside your app bundle.
However, since ABI stability, Apple is now able to utilise Swift in the iOS and macOS SDKs, so that your app can use Swift to interface with the platform. It allows for far more expressible APIs and beter integration between your app and the OS.
But …
Now your app calls swift code from:
The Swift standard library (which could be bundled as you suggest)
Your own code (which is obviously bundled)
Frameworks bundled in your app bundle
The platform SDKs (can't meaningfully be bundled)
This means that your app have to be built for the same (or newer) version of the Swift runtime as whatever is running in the target device. Since iOS 12.2 is shipped with Swift 5.0, your app can not use 5.1 runtime features if you want to target 12.2 or older.
Note that this only applies to runtime features of Swift. You can compile a 5.0 compliant binary using the Swift 5.1 compiler as long as all your code compiles down to features that are available in the 5.0 runtime.
It is technically possible to bundle shims into the app, and Apple may opt to do this for some features, like they did when they "backdeployed" ARC to older versions of iOS a few years ago. But engineering work has to be done for each such case, and we can't expect all apps to include the newest Swift runtime as you suggest. Unfortunately.
3 Likes