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

Picking your Swift toolchain from xcodebuild

With Xcode 8 xcodebuild uses Swift 3 to build by default. This will be great in about six months, but right now it’s somewhat of a pain. I am using Carthage as my dependency manager and all of those are using Swift 2.x still.

If you want to build your Carthage dependencies (or anything from the command line for that matter) using Swift 2.3, add the TOOLCHAINS parameter.

TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 carthage build  

Update: As of Carthage 0.17 you can use a --toolchain option. This doesn’t help with raw xcodebuild obviously.

Read more about. . .

Auto Layout Debugging In Swift

I’ve been working with Swift primarily over the last month. Recently I started working on a new custom interface piece that was having some rendering issues with its layout constraints. I went into LLDB and quickly realized that using private methods such as _autolayoutTrace and recursiveDescription to print out a hierarchy of my views and see ambiguity wasn’t possible out of the box.

The reason for this is that when you’re in a Swift frame, LLDB is expecting you to call a Swift method it knows about. Since _autolayoutTrace and the like are private API, they don’t have any visibility to Swift. Safety!

There are a few different ways to get around this. The first is straight in LLDB. You can use the expr command to tell LLDB that you are passing it a snippet of Objective-C code like so:

<code class="bash">expr -l objc++ -o -- [[UIWindow keyWindow] _autolayoutTrace]  

What we’re doing here is printing out our entire view hierarchy to the debugger. Frequently typing that long of a statement is obviously a bit tedious, so I tend to put it in my .lldbinit file.

<code class="bash">command alias alt expr -l objc++ -O --[[UIWindow keyWindow] _autolayoutTrace]  

Now you can just type alt and get the same output from the debugger.

You’ll notice that I am throwing this out for the entire contents of the keyWindow. I haven’t been able to find a way to pinpoint it down a single property such as self.view, so if you have any feedback on that, please share!

If you’re mixing Objective-C and Swift, you likely already have a bridging header. You can bridge add a category on UIView that exposes the recursiveDescription and _autolayoutTrace methods to Swift.

<code class="objectivec">#ifdef DEBUG

@interface UIView (LayoutDebugging)

#pragma clang push

#pragma clang diagnostic ignored “-Wincomplete-implementation”

- (id)recursiveDescription;

- (id)_autolayoutTrace;

#pragma clang pop

@end

#endif

And the implementation file.

#import “UIView+LayoutDebugging.h”

#ifdef DEBUG

@implementation UIView (LayoutDebugging)

// Nothing to see here!

@end

#endif

Let’s walk through this. You’ll notice that I have the entire thing wrapped in an #ifdef DEBUG statement because I am working with private APIs that I presume the App Store usage checker would flag and reject your app against. With the #ifdef, I am saying that it should only be included on development builds. Apple will have no idea what abuses we are committing since it will never make it to the release builds!

The other atrocity I am committing in this file is the use of #pragma clang diagnostic to tell the compiler to ignore any ‘uninmplemented method’ warnings that will pop-up from not being able to find an implementation for the two methods we defined in our category. Since they exist as private API, we don’t need to reimplement them.

Now if you break in a Swift frame with LLDB and try to call self.view._autolayoutTrace() you’ll get an output you expected.

Happy debugging!

If you’ve found this post useful, and want to learn more about how to best take advantage of Auto Layout in your OS X and iOS apps, be sure to purchase my new book Achieving Zen With Auto Layout

Read more about. . .

Learning How To Make Sausage

Let’s imagine there is someone out there who watched last week’s WWDC keynote and thought to themselves, “This is it! Now! Now is the time for me to learn to program and build an iOS app!”

Nevermind that they are about 6 years late to gold rush, it’s an exciting proposition. Programming is fun! I come from a family of builders. The only difference between my father and grandfathers is they built homes with hammers. I sit in front of a keyboard all day typing and looking at cat GIFs.

I digress. You want to learn to be an iOS developer. What are you supposed to do? Aaron Hillegass (whose books I credit with teaching me this stuff way back when he was the only person writing about Cocoa development) says you should learn Objective-C. Ash Furrow and a few others say you should learn Swift because Objective-C is too hard.

Guess what? It doesn’t matter what language you want to learn.

If you want to be an iOS developer you realistically have four options:

  1. Objective-C: old faithful.
  2. Swift: New hotness.
  3. Xamarin: The crazy kids in the corner who want to use C#.
  4. RubyMotion: Know Ruby? Tired of arguing with DHH about whether tests are dead? You too can build an iOS app.

I’d lean towards choosing one of the first two options because they are first-party solutions provided directly by Apple, but the language you choose to learn matters little compared to learning the frameworks. The Cocoa Touch frameworks have always been the secret sauce. Whether you’re using Objective-C, Swift, C#, or Ruby you’re still going to have to learn how to use a UIButton and a UITableView.

Will you be more of an iOS developer because you took the time to learn Objective-C and it’s 20+ years of history versus Swift and its eleven days? Nope. Your customers care about what’s on the surface of your app: does it look, interact, and feel like an iOS app. If you can do that, the language doesn’t matter.

There is no right answer to this question. Choose what the language that speaks to you and then go build something awesome.

Read more about. . .