Swift's Evolution

I'm usually pretty good at inferring where Apple is going with their projects and products. With Swift, I'm left shrugging. Hopefully the purpose of Swift and how it relates to Apple becomes less muddy next week.

Since 2004 (!) I have been attending WWDC on a regular basis. My first time was on a student scholarship thanks to some incredibly poorly written Objective-C code back in the Mac OS X Panther days. Fast-forward to 2017 and we've gone from Apple the underdog computing platform to Apple the juggernaut that has four top-tier platforms.

After you've attended a handful of WWDC's, you start to realize the pattern. Unlike a conference like TED which explicitly puts the theme of the event on the cover, WWDC is a bit more subtle. If you attend enough sessions you start to realize both what Apple is interested in this year, but also in this new iOS era, where they are skating towards in the fall.

Skating to Where the Puck Is Going

When Apple introduced Auto Layout with iOS 7, they started pushing the idea of having both iPhone and iPad apps being built from the same core interface elements with minimal additional effort by the user. It was also a pretty good hint that Apple had their eye on a larger iPhone, someday. When size classes were introduced with iOS 8, they were literally beating you over the head saying larger phones were coming.

Size classes were an important announcement in 2014 with iOS 8, but the biggest announcement was by far the introduction of the Swift programming language. Though not marketed as an absolute successor to Objective-C, most have taken the introduction of Swift as a pretty good indication of where Apple wants to take software development for their platforms for the next decade or more.

With Swift, Apple gave themselves a clean slate to build a modern language for mobile development, without the legacy of a programming language that was designed for NeXT Cubes in the 80's. Swift checked many of the boxes that new and old Apple developers had been clamoring for by offering things like static typing, optional types, and not having to think about pointers for the majority of mainline use cases.

Swift also infused a lot of new ideas into development on Apple's platforms. Subclassing began to be seen as a last resort when protocol-oriented programming and value types couldn't be used. A traditional for loop was passé. Instead, map, flatMap, and forEach were how you flexed your Swift muscles.

Living on the Edge

The first version of Swift was, dare we say, challenging and I avoided using it in production. With the release of Swift 2.0, the water seemed cool enough that the first bits of Swift code landed in production at the day job. In fact, most of the new code being written at that point was in Swift rather than Objective-C. The tooling still suffered from a lack of reliability and stability, but I kept reminding myself that I was using a new, rapidly iterating language and that just comes with the territory.

Swift 3 was the first release after the open sourcing of the language, and honestly where I think my love affair began to wane. After being open sourced, Swift started to feel like a language that stopped actually moving forward in ways that made sense to me. Removing traditional for loops and increment/decrement (++/--) operators were pushed through the Swift proposal process as improvements the core language by the fact that there were "better" ways to replace their functionality. From a theoretical perspective, that makes a lot of sense. Practically, I was left wondering why it was worth the effort when there are still real problems needing to be solved.

The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium. In my decade of professional development, I have never had a worse experience. The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward. How that migration tool ever made it through QA is beyond me, but I'd have felt better if Apple just said "good luck" instead of offering a half-baked utility.

One can argue that renaming every method API method to be more "swifty" was worth the headache. I even agree to a point, but I also don't believe Swift 3 dramatically improved my experience as a software developer, especially when compared to the effort to get there. In fact, most of the decisions made since Swift was open sourced have left me scratching my head as someone just wanting to use the language to write iOS apps.

Practicality vs. Ideology

I'm a practical iOS developer by day. I try to use a value type where it makes sense, but I also still design my table views the old fashioned way with delegates and data sources. I still use Core Data for persistence. And I still use KVO where it makes sense.

From the outside, it seems like important milestones like ABI stability continue to be delayed as Apple and its open source contributors continue to chase the dream of designing the most pure language they can. Removing "legacy" operators and arguing over access levels seems to have taken priority over actually moving Swift forward as a first class language for Apple development. The problem with that is that software development isn't pure. It's messy. I've never written a perfect line of code in my life. I don't plan to either. Fixing a language in post is obviously harder than pushing a new build of an iOS app, but chasing perfection is a fools game no matter what the project is.

As a production developer I need ABI stability because it prevents me from having to recompile my dependencies every time the language is upgraded. It will also hopefully allow me to shave 8 megabytes off my download by no longer including a Swift runtime in every release. My product managers need those 8mb for more analytics libraries! I'd rather Apple spent its time giving me a concurrency story along the lines of async/await instead of looking for new ways to make protocol extensions useful in scenarios that just don't make sense for my shipping products. And for god sake, improve compile times. I only have one life. I'd like to spend less of it watching a progress indicator.

I realize that the tools team and the Swift team are separate, but its hard to separate the two when Swift's primary method of development is Xcode. Xcode's quality as a Swift development language has never been great with its constant indexing, opaque compile errors, not great typing auto-completion, and lack of refactoring support still. With zero insight into the inner workings of Apple, it still feels like the language hasn't been embraced nearly as heavily internally as it has been externally. If it was, I'd believe that Xcode's Swift-related issues would be resolved much quicker than they have been. The biggest pain points external developers face always seem to be resolved once they become issues internally at Apple. If Apple can't use Swift to build its frameworks or its internal products because ABI stability is missing, they don't see all the warts we do.

Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. Instead, the language design focuses on implementing functionality that would benefit server-side Swift, Playground demos, and showy conference talks. If that's the goal of the language, I sure wish they'd come out and say it. Right now it feels like I'd have been better served by continuing on with Objective-C, which is still being improved in meaningful ways, rather than going all-in on Swift.

Read more about. . .

The Next Five Years

Just when I thought I was out, they pulled me back in.

My confidence in the iOS platform has been waning over the last 12 months. iOS 7 was a hard upgrade to swallow both in terms of the changes and the work it brought. A questionable visual refresh, but few improvements to a core experience that finally felt behind what the competition was offered.

My time with C# and Azure showed me the sharp edges in Objective-C that I wasn’t fully aware of before. It’s not that Objective-C is a bad language (it’s pretty great), but it’s also built on a foundation that makes things that should be simple not so simple.

Even the developer tools were lacking. The iOS publishing and beta experience has been laughably bad for years, especially compared to what Google offers Android developers.

And then in two hours, Apple shut me up. They pretty much offered a solution for every single thing I have bitched about over the past five years. Extensions, CloudKit, a new iTunes Connect. And Swift, an entirely new programming language that will likely power the future of iOS and OS X development for years to come.

I came into this years WWDC fairly mellow to what would or wouldn’t be announced. There wasn’t any anticipation or excitement the night before. Just a standard amount of curiousity. After the Keynote, I can’t remember being that excited since the announcement of the original iPhone. They blew the roof off Moscone.

With my entire list of complaints about the Apple platform resolved, what am I supposed to complain about now? I have spent the better part of the last week thinking about an entirely new list of things for Apple to work on these next five years, so that I can both continue to have something to nitpick and because I truly believe they will enhance the platform in meaningful ways.

  • A Global Accounts System: Authenticating with your Facebook or Twitter account on iOS is as simple as accepting an alert view pop-up. Authenticating with Foursquare, Glassboard, or any other third-party auth provider requires either manually entering passwords or using a URI scheme to jump between apps. Being able to set any third-party service as an auth provider a la Twitter or Facebook would benefit all users of those services. (Radar: 17226236)
  • async-await: Swift is wonderful until you have to create a dispatch queue. Then you remember that concurrency is still way too hard on Apple’s platforms. C# has solved this in a meaningful way with their async-await keywords that make asynchronous programming incredibly simple. (Radar: 17226224)
  • Better Refactoring Tools In Xcode: Xcode 6 is a wonderful update, but its ability to refactor code in meaningful and reliable ways still lags severely behind Android Studio and Visual Studio.
  • Token-Based APNS: The certificate dance that you have to jump through to work with Apple’s Push Notification Server is horrendous when compared to other solutions. Being able to register for a secret token and use that to authenticate is far simpler to integrate than the certificates and provisioning profiles needed presently. (Radar: 17226189)
  • CloudKit REST Endpoints: CloudKit is designed to excel on iOS and OS X, but there are server-side scenarios where it would be beneficial to be able to hit a CloudKit end point and pass data to a user’s account, or register a silent push based on a third-party data source hosted remotely. (Radar: 17226182)
  • Default Apps On iOS: With great third-party apps that are offering full replacements for standard apps like Safari, Mail, and Calendar, it’d be ideal to be able to associate them with iOS so if I use Mail and tap a link I can have it open in Chrome, my preferred iOS browser. (Radar: 17226170)

Here’s to the next five years.

Read more about. . .