I find this interesting, considering that .NET went the other direction. The .NET Framework was operating system bound, while the modern .NET (Core) is a separate installation or ships with the app or is even AOTed.<p>Maybe Apple is more aggressive in adopting Swift as their operating system language, because Microsoft always has this split that the Windows division was C++/COM and .NET did not really fit into their world.
I really wish that Apple would provide an alternative C API to its system frameworks, even if it would be inconvenient to use (similar to Microsoft's COM APIs - terrible to use directly as C API, but at least it's possible, and most importantly, the COM APIs provide a stable ABI and allow proper interface versioning - so old and new interfaces can live side by side).<p>Language bindings could then directly go through the C API instead of having to go through an ObjC- or Swift-shim, or calling directly into the brittle ObjC runtime functions (is there even something similar to the ObjC runtime for Swift?, e.g. a C API to create Swift objects and call methods on them?).
While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments.<p>That's my main gripe with apple's approach to swift and swiftui. Yes, tech is getting better every day, but unless you target latest OS version, you can't use new fresh stuff until it's on enough devices around you. And that pretty much guarantees that no matter what apple adds, you still have to wait a year or two until you can safely start using it.<p>In modern android, kotlin(and compose) also part of the system, yet all the apps do not rely on the system libs, but rather inject the latest available runtime with each of the apps. It takes more space, but instead allows developers to target latest available stack, no matter what core os this app is being run on.
I recently built a Swift app for the first time, and I was so pleasantly surprised. It's really easy to pick up, I also did zero styling or performance optimizations and it's pretty and fast.<p>My only regret was not using SwiftData (since it was only released with IOS 17), CoreData is not that nice.
"Because this was the very premise of Apple’s OS-based library distribution model: apps compiled for Swift 5 would work with an OS built on Swift 6; apps compiled with Swift 6 would still be able to “backwards-deploy” to an OS built on Swift 5. Without this, Apple couldn’t use Swift in its own public APIs."<p>How is an app built on Swift 6 runnable on an OS with just Swift 5 runtime? I would have thought developers have to target the minimal Swift (and iOS version) at build time and live with the features available then.
The comment about code signing perhaps being a blocked for third party sdk/library deduplication doesn't seem to also consider the fairplay DRM on iOS apps. As far as I know, the code (.text) segment of all iOS app store binaries are encrypted. I don't know the details about the encryption scheme (I would assume it is perhaps uniquely encrypted keyed on the user's appleid?) but it sounds like this would be a larger problem than just code signing signatures varying between publishers (and I would assume all appstore apps are re-signed by a single apple appstore authority, although enterprise/adhoc apps probably aren't).
Go's creator still uses and promotes Go. Python's creator still uses Python. C++'s creator still uses and promotes C++. Java's creator still uses and promotes Java. But Swift's creator no longer uses Swift AFAICT.<p>Why?
In the time since this article was published, a new feature was introduced in Swift 5.8 that addresses the issue: @backDeployed [1] allows Apple to include a default implementation for a new API method that will be used when running on an older version of macOS.<p>It only works for functions/methods, but it will allow devs to use new APIs sooner!<p>[1]: <a href="https://www.hackingwithswift.com/swift/5.8/function-back-deployment" rel="nofollow noreferrer">https://www.hackingwithswift.com/swift/5.8/function-back-dep...</a>