Justified concerns about the consequences of ABI stability?

Evolution Discussion
61

It's definitely a trade-off, but it's not all downside.

I'm actually really excited to see better interfaces for the platform libraries. I think this is a really big deal - not just for the health of the project, but also for Apple's OSes.

One of the reasons this is so exciting for me is because I remember Microsoft's move to try and deprecate the Win32 API with Windows Longhorn (which became Vista) in the early 2000s. The plan was to introduce a set of new platform libraries called "WinFX", written in .Net, including hundreds of new APIs. Win32 would be kept for compatibility but be frozen - all new features would only come to the new SDK. To be clear: there would be no new C APIs in the future - you would have to move to .Net. Which, as you can imagine, people were absolutely thrilled about.

Microsoft was full of confidence following XP, and they really tried to make the most advanced technology platform they could imagine. They wanted to basically rewrite the OS overnight. WinFX came with a new, vector-based graphics subsystem called Avalon which was built on DirectX, a new communications subsystem called Indigo and a radical new storage interface called WinFS which indexed files in a schema-driven relational database. Anyway, it turned out to be a bit too much, performance was rubbish, and people just didn't like being forced to use .Net - but it was an interesting attempt to break from C, the Win32 API, and all the cruft that had accumulated. "The idea is to significantly reduce the number of APIs and make the APIs more standardized. Today, there are over 76,000 Win32 APIs, and countless wrappers. With Longhorn, Microsoft hopes to reduce the API set to 8,000 to 10,000". After they hit reset, they chopped up various parts of WinFX in to .Net 3.0 and Win32 got to live on.

But Microsoft still knew they needed a modern platform SDK. They had another go with WinRT which originally used C++ with a bunch of extensions. Now it's called the Universal Windows Platform (UWP). These days the Windows platform SDK looks thoroughly modern with features like .Net generics, events and async/await. Honestly, the SDK for Apple's platforms is pretty lacking by comparison. At the same time, Google is developing their Fuchsia OS and Flutter SDK, where Apps are primarily written in Dart.

So, as I see it, there has been a big push in the industry for years to replace legacy C interfaces with something more modern. We don't know what Apple's intentions are for Swift, but I assume it's part of their answer to Fuchsia and WinRT. I don't think they're going to all of this effort just to stop at some overlays for Objective-C. I think Swift was made to become part of Apple's OS, and that's a large part of why the project even exists.

But it's exciting, right? Is it just me who is excited by this?

13 Likes
62

It's definitely exciting! I can't wait to see what they do. I just hope the platform APIs aren't set in stone before we have some of the core language features they might benefit from (concurrency, generics enhancements, ownership, etc).

63

Even if it takes a couple of years, it's not such a big deal in the scheme of things. I would guess that lots of developers forgot or never knew that older versions of iOS didn't support auto-zeroing weak pointers. We just take it for granted now.

3 Likes
64

I couldn't agree more. What matters most to me is the quality of the APIs we get in the end. :slight_smile:

3 Likes
65

Agree. The introduction to async/await will not be worst than the introduction of Block and libdispatch in Obj-C. People had to wait to be able to use it, but nowadays, nobody remember how it was before.

1 Like
66

I'm actually really excited to see better interfaces for the platform libraries.

I wonder what kind of API's we'd actually see that take advantage of Swift features. Unless Apple were to maintain two sets of API's for Obj-c and Swift, they'd have to dumb down the Swift interface to an Objective-C level.

67

Yes, but there were no other modern language options at that time either.

68

Many of us are hoping (or expecting) that we’ll see Swift-native frameworks that adopt idioms and techniques that are not possible in Objective-C. This would be a platform transition on the magnitude of Carbon to Cocoa and would take at least as long to complete, possible longer since this wouldn’t be starting with the experience and history that Cocoa did.

5 Likes
69

ObjC is generally more dynamic and permissive, though. I think they'll continue to provide Obj-C facades, but native Swift code will hopefully be able to take advantage of Swift-only features like compile-time generics. I don't think they'll "go full Longhorn" and not support Obj-C any more.

That's an Apple policy decision, though. Not really anything to do with this project. My point was just that if you're a Swift developer targeting Apple platforms, there are potential upsides that could make up for the pain. Maybe we'll find out more at WWDC.

2 Likes
70

Right now, apps have to carry a copy of the Swift 4 libraries, right? And after the first version of mac/i/tv-OS with Swift 5, the system will include a Swift 5 shared library and apps written to that will just refer to the system copy, right? Will there be an in-app copy of the Swift 5 libraries available, so apps that target older OSes can use Swift 5 the same way they use Swift 4?

I ask this because I'm wondering how it will scale with later versions of Swift. Let's say that after Swift 5 is released and all of Apple's OSes include a Swift 5 shared library, we add new features. Xcode Y gets Swift 6 with async/await support. Then Xcode Y+1 comes out with Swift 7 which adds fixed-sized array support. Then the next versions of Apple's OSes are released with a Swift 5/6/7 shared library.

Now let's say I make a new app that uses asynchronicity and FSAs. Will there be a in-app library that includes everything up to Swift 7 that I can deploy all the way back to Swift-4-era systems? Or will there be an in-app library that only includes the Swift 6 and 7 stuff and assumes that the Swift 5 shared library will exist, and therefore I can only deploy back to the first systems with the S5SL? Or am I limited to just the systems with the Swift 5/6/7 shared library? Or can I choose which one of these levels to support?

71

The problem is not the resilience, the problem is the yearly big upgrade of iOS, macOS etc...

For me the best solution would be that before any app download or update in the app store the system library will be updated to the latest possible version. And if there are apps which do not allow this, the user should be warned (similar to the 32-bit warning).

1 Like
72

The whole point of having stable ABI is to be forward and backward compatible, so a system don't have to contains different library version. An application compiled using Swift 5 will be able to run with the Swift 6, Swift 7 and any future runtime and libraries (unless there is API deprecation and removal, but this is an other story).

Any Apple OS will contains only a single copy of the Swift shared libraries.

For the other question, read the previous answers.

4 Likes
73

It's still not too clear, and I don't think my own questions were clear to start. So here's a hopefully better-stated set of queries.

  1. The Swift 5 shared library will come out with a major Apple OS family release, right? Will the shared libraries for Swift 6, 7, etc. also match major releases?

  2. If path #1 is chosen, then how will Swift Current+1 be developed, since there wouldn't be a matching shared library yet?

  3. If Swift 6, 7, etc. can come out between major Apple releases (i.e. path #1 isn't chosen), will there be app-local libraries going just from 5-to-6 (5-to-7, etc.) that we can bundle until the next major Apple release? Once a major Apple release happens, will the app still use its app-local Swift library? Or will it silently use the updated Swift 6 (7, etc.) shared library?

  4. Is there going to be an app-local Swift 5 (6, 7, etc.) library for operating systems before the Swift 5 shared library, like we're doing now for Swift <5? Or is that going to be a hard cut-off?

74

1: They might not wait until the next major release. APFS was deployed on iOS in a minor version bump, for example.

2 & 3: Nobody can make such concrete determinations about the future. Exactly what Swift 5.5 or 6.0 could bring, and which of those things may be deployable to older devices is TBD until those releases exist and can be assessed.

4: I'm not sure if there's an official statement on that, but some of the Apple developers here have said the "App Thinning" which is part of the Appstore infrastructure could be used to only include the app-local Swift 5 libraries on older systems. Put it another way, nobody has said ABI stability will require anybody to drop compatibility.

2 Likes
75

Swift 5 runtime is an other relevant example.

1 Like
76

We wrote a blog post to gather the questions raised in this thread and provide answers in a centralized place:

25 Likes
77

Thanks for this well laid out and easy to read post @Joe_Groff.

3 Likes