Swift 4.0 Still Won’t Shake Objective-C

Swift 4.0 is coming.

As programming-language iteration goes, Swift is moving at a fairly rapid pace. Less than three years after Apple unveiled the language, it’s heading for the release of Swift 4 this fall. But Swift’s predecessor, Objective-C, isn’t dead yet.

In a blog post on Swift.org, new Swift boss Ted Kremenek lays out the team’s plans for Swift 4. Happily, we’ll find ourselves with reverse compatibility to Swift 3. It’s a departure from the previous hardline stance that apps written in Swift 2.x must update to Swift 3, lest Xcode refuse to compile them.

Still, you may encounter the rare error with language compatibility. Per the blog posting:

The first mode, Swift version 3, is the default for existing code. Under this mode, it is a strong goal that the vast majority of sources that built with the Swift 3.1 compiler continue to build with the Swift 4 compiler. The exception will be bug fixes to the compiler that cause it to reject code that should never have been accepted in the first place. These cases should be relatively rare in practice.

As the team also notes, migration from Swift 3 to Swift 4 will be less painful that it was from Swift 2 to Swift 3. Multiple-version support also means apps with Swift 3 frameworks in place won’t have to update. You can write an app in Swift 4 and point to a Swift 3 library or framework. This also works for Swift 4 packages that need to access their Swift 3 counterparts.

Swift 4 Has Some Bad News

Compatibility between Swift versions three and four is nice, but there’s an elephant in the room: application binary interface (ABI) stability remains elusive.

If you’re unfamiliar with ABI, here’s a primer: it’s what allows your app to access outside libraries and resources without the need for constant updates if those resources change. An app that accesses an outside application programming interface (API) does so through the ABI, and if that API is updated or altered, your app doesn’t need to do anything to accept those changes because both the app and API operate within the ABI’s specifications.

Keeping things Apple-y, that means Objective-C is still a thing, though it’s slowly being deprecated by developers, anyway. Because ABI stability hasn’t yet been achieved within Swift, Objective-C will remain the language du jour for libraries and frameworks. Le sigh.

For those keeping an eye on the Swift ecosystem, this isn’t all that surprising. The team is currently focused on language refinements, most notably an “overhaul” of the Strings API in Swift 4 “where a key focus is to improve the ergonomics of the API and its performance.”

The Swift ABI manifesto also lays out where the team is headed in terms of total compatibility. A large part of ABI stability is the need for support across multiple versions of the language, which is clearly not happening yet. Conceptually, ABI stability for Swift can only happen with apps written in Swift 3 or later, which may be the reason for the hard-nosed conversion demand last time around.

Things are still going as planned in terms of the Swift roadmap, but that the aging Objective-C remains a major story when it comes to Swift 4 is befuddling. It’s either a sign the Swift team isn’t in a hurry to distance iOS, macOS, tvOs and watchOS from Objective-C – or a sign that the developer world is. Sadly, only time will tell.

Comments

One Response to “Swift 4.0 Still Won’t Shake Objective-C”

July 22, 2017 at 11:27 am, Eljay said:

In Swift’s defense of its rapid evolution, other popular languages like C++ are undergoing change as well. Sometime not fully backwards compatible, sometimes deprecating previous best practices, sometimes painful, sometimes long overdue and hardily welcomed.

Programming languages are much like human spoken languages. There are two kinds of languages: those that are evolving, and those that are dead.

As programming languages evolve, programs written in them incur “external” technical debt. Keeping on top of that external technical debt is one of the costs of doing business.

Reply

Post a Comment

Your email address will not be published.