Is Swift Moving Too Fast for Its Own Good?

Swift 4 is coming.

Swift is rising fast. In the pantheon of programming languages, Swift is the newcomer, but quickly earned respect thanks to the support of Apple and the developer community. Now, some are pointing out that it might be iterating too rapidly. Is that a fair claim?

Launched at WWDC in 2014, Swift was meant as an eventual replacement for Objective-C. It was simple, intuitive, and added many features that enticed Objective-C developers to give it a shot. In late 2015, Apple brought Swift to the open-source community, effectively allowing it to grow on its own merit.

Ever since, plenty of entities have latched themselves to Swift’s wagon. Independent developers have created a sort of cottage industry around it, launching newsletters and conferences dedicated to the language. IBM, once at odds with Apple, has effectively taken over the ‘enterprise’ side of Swift development.

Apple typically commands such interest and excitement around its products. Even so, Swift is now on version three, rapidly heading towards version four. With the change from version two to three, a lot of code was rendered useless. Here’s how the language’s open source management team described the transition at the time:

Swift 3 is a source-breaking release, largely due to the changes in SE-0005 and SE-0006 [both related to APIs]. These changes not only impact the names of the Standard Library APIs, but also completely change how Objective-C APIs (particularly from Cocoa) import into Swift. Many of the changes are largely mechanical, but they can be numerous in a typical Swift project.

To help with moving to Swift 3, Xcode 8.0 contains a code migrator that can automatically handle many of the need source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny.

Move Swift and Break Things

Nobody said Swift would be seamless.

Moving so rapidly has caused some headaches, especially with the code-breaking move from version two to three. Developer Craig Hockenberry outlines a typical issue Swift developers have in 2017: after using sample code to build a project, he tried running it in Xcode:

Everything is great until try to build and run that project. Xcode displays 12 issues that you’ll need to deal with before you can try out the sample.

A bunch of the errors are due to private protection levels on instance variables. Unfortunately, there’s no automatic fix for this issue. But even though you’re no expert in Swift, you find that changing the definitions to public seems to clear things up.

Hockenberry used Apple’s own code samples for a macOS app. PCalc developer James Thompson hit a similar stumbling block for a new app he’s working on:

It’s a workflow problem developers can’t easily get around. Noting that we tend to use sources such as Stack Overflow to solve problems (oh, yes you do…), Hockenberry said: “It’s gotten to the point where every time I come across some information written in Swift, especially on Stack Overflow, I cringe. I know that I’m going to have to not only figure out the code, but also which version was used for the answer.” In addition:

For many of us, sample code is the best documentation possible. It not only shows you an API, but also how it works in context. This sample code appears on a lot of places besides the web: it’s in WWDC videos, PDFs of presentations, books, and downloadable projects like the one used above.

So how swiftly is Swift really growing? It’s easily the core of this issue. GitHub data suggests it’s easily one of the most popular “actively developed” languages on the site, with nearly 37,000 stars and over 5,000 forks. TIOBE routinely ranks it highly as well, where it’s already challenging Objective-C for command of the Apple ecosystem. Upwork ranks Swift as the ‘most in-demand language’ around. Anyone who’s ever tried to follow the evolution email thread knows it has a lot going behind the scenes, as well.

In a way, this is where we were supposed to be years ago. Those familiar with Swift’s development within Apple tell me Swift 3 is largely the company’s original vision for the language, but Apple scaled earlier builds back in order to make it “friendlier” to Objective-C developers. It helps explain why the types of build-breaking changes developers are noticing now didn’t roll out on day one.

That (and releasing it to an open-source community governed by Apple engineers) also tells us that Apple is playing a smart long-game with the language. It could have forced Objective-C developers into a hard left turn with Swift, but that would have sparked immediate, lasting outrage. Think of what might have happened if Objective-C developers in 2014 were asked to adopt a new language that didn’t correctly compile Objective-C APIs, wouldn’t work with legacy code, and made a host of style changes that rendered it almost unrecognizable. Mutiny.

So while the current issues with Swift are noticeable and aggressively annoying, there’s good reason for it, both today and historically. Swift’s migration to version four, which still doesn’t shake Objective-C (for those who would like to) APIs and libraries, also doesn’t bork Swift code from version three. It’s meant to have better ABI stability, which means the real work of leaving Objective-C behind can really begin.

Hockenberry also echoes a familiar tone at the end of his blog post: “It feels like folks are still searching for perfect, when what many of us want is just a great and stable language.” Swift 3 and the language’s overall progress is oddly a good example that we’ll get there faster than we thought, but slower than we’d like.

Post a Comment

Your email address will not be published.