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-Cisn’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.

Related

4 Responses to “Swift 4.0 Still Won’t Shake Objective-C”

  1. 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.

    • Different perspective. There are two types of technologies: 1.) mature and stable, and 2.) work in progress. As a whole, the Swift experiment is a #2 at this point.

      RE: cost of business. If you’re managing business strategy, operating and resource cost, etc. etc. relative to quicksand technology, then you’re not making smart business decisions. Adding unnecessary overhead and cost just to say you’re riding the Wave of Future Apple Technology. It sounds really good to software engineers; bad decision for those that care about not fixing things that shouldn’t have been broken to begin with. A good tech team can port and migrate a large codebase when the time is right to do so, if that time ever comes at all. Real world projects have to take into account real world problems — for example, 3rd party frameworks. If you can’t even lock down an ABI, then you’re incurring unnecessary real world technical hurdles and development costs.

  2. The headline sounds needlessly clickbaity, given the contents. Swift is being adopted faster than any programming language in history. Why slap a title on the article that makes it sound like the big story is how *little* it has accomplished?

    “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.”

    Swift’s effective ABI today is the Objective-C ABI, as you say, and it’s working very well. I don’t see anything “befuddling” here. Apple developers know that a native Swift ABI is important but, unlike 21st century journalists, they realize it’s more important to get it done well than to just get something done quick.

    “Because ABI stability hasn’t yet been achieved within Swift, Objective-C will remain the language du jour for libraries and frameworks.”

    This statement is clearly nuts, and doesn’t reflect reality at all. There’s many thousands of Swift libraries and frameworks, and we have no problem using them today. The only restriction from the lack of a native Swift ABI is that we have to compile them ourselves, or guarantee we’re using exactly the same compiler as whoever compiled them for us. That’s not ideal, especially if you want to distribute a closed-source library, but it’s not making us write all our libraries in Objective-C, as you seem to suggest.

  3. Objective-C will remain the language du jur for all _professional_ iOS development, because Swift, sadly, is still an educational language designed for non-software engineers.

    It still breaks OOP paradigm, and is horrible to use in a group environment.