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

My Ultimate Developer and Power Users Tool List for macOS Sierra (2017 Edition)

This is the latest installment of my must have must have list of tools and utilities as a macOS and iOS developer. The idea for this list was shamelessly ripped off from Windows developer Scott Hanselman whose list has long been an enjoyable read when he updates it.

There have been significant changes since I last did one of these. I’ve tried to mark anything new in bold.

Hardware

Since I last updated this in 2013, my hardware has changed significantly.

I am still maintaining a dual Mac setup. My daily driver is a Late 2015 27" Retina 5K iMac with a 1TB SSD and 32GB of RAM. After nearly five years, I replaced my old 2010 iMac that was starting to show its age when compiling Swift. Swift eats hardware for breakfast, lunch, dinner, and fourth meal. I’d say this was Apple’s genius plan to sell more Mac hardware, but they can’t be bothered to update their hardware lineup regularly so there went that theory.

At home I am using my 15" Retina MacBook Pro with a 1TB SSD and 16GB of RAM. This is one of the new Touch Bar models and it’s fine. I somehow have been able to survive without a physical escape key or a row of function keys. I assume this makes me lose some sort of geek cred. Sorry, nerds.

I used to be a big Dropbox user, but I’ve moved all of my files over to iCloud Drive because it’s good enough. I take advantage of the Shared Desktop and Shared Documents functionality of macOS Sierra. Photos are stored in iCloud. Calendar and Contacts too. It works, usually. There wasn’t anything wrong with Dropbox, but it was just another thing I was paying money for that wasn’t super necessary when there’s a good enough alternative baked into the OS now.

In terms of accessories and upgrades:

Software

I am really hard on software. This is for a variety of reasons, but I think it is because I build it myself. I have always envisioned that directors and actors can sometimes lose focus during a movie as they judge the decisions others made in their productions. I feel like I do the same thing with software. I loathe poor and/or non-native user interfaces and cherish simple tools. These are applications I constantly rely on.

The Essential Five

Developer Tools

User Tools

Read more about. . .

My iOS Development Kit - January 2016

If you surveyed me annually, you’d likely find that my toolkit for building Mac and iOS applications changes a bit year over year. This year, however, the changes seem to be even bigger than before. With Swift 2’s release, I made the full transition from Objective-C to Apple’s new language du jour.

The transition has not been without growing pains (hello, constantly crashing debugger!), but overall I am writing better, more idiomatic code. And this is coming from someone who spent the last decade happily writing Objective-C. Since I’m making the transition, I’ve also used it as an opportunity to re-evaluate the third-party libraries I am using in my client applications.

I tend to have a fairly reserved stance on third-party dependencies. I am not vehemently against them like some, but I also don’t want to turn my app into a Lego set where I’m merely piecing together library after library that I don’t fully understand. The tools below are things I have used and successfully deployed to production.

Carthage

In the Dependency Wars, I have tried them all. I started with vanilla Git submodules, and did a brief tour of duty with Cocoapods. Submodules didn’t offer nearly enough wins for the management overhead I seem to have. Cocoapods worked for the most part, but I have fundamental disagreements with how they package and build their products.

Carthage seemed like a happy medium for me. I get the wins of using some sort of dependency management system, and it sticks with using the shared Xcode schemes that are bundled with the project itself.

RxSwift

This is the most recent addition to my list, but it’s one I’m growing to enjoy most. Functional programming is what all the hipster developers are doing these days, so I am trying to wrap my head around it. I may not understand why they wear wood framed glasses, tight jeans, and so much flannel, but I am starting to come around to the idea of building things functionally.

RxSwift is from the same folks who do Rx.net, RxJava, and a host of other implementations, which may or may not be appealing to you. When learning something new, documentation is important and I’ve found the docs for RxSwift to be pretty well done. There’s still cases where the generic ReactiveX documents are “TBD” in terms of RxSwift, but having the header docs fills in many of those gaps.

My biggest complaint with RxSwift isn’t so much a complaint with the library as it is with the idea of functional programming. It is a major change in how you think, so I spent most of my first few weeks re-reading docs, cursing and trying to understand what was actually happening. Eventually it will click, and when it does it’s a really nice way to build iOS libraries.

RxSwift includes a library for making UIKit more reactive, but I’m shying away from it presently. Right now I have limited RxSwift mostly to integration with network modules I build. I reserve the right to change my mind about this in the future, but right now delegates and data sources don’t bother me that much.

SwiftyJSON

It is a toss-up whether there are more Swift JSON parsing libraries or Republican presidential candidates in the US. I don’t really have anything negative to say about SwiftyJSON. It works and saves me from writing JSON parsing code over and over again.

You can likely choose one of the other 107 libraries and it will do pretty much the same thing: just like a Republican presidential candidate!

Realm

I have used Core Data since it was introduced way back in OS X 10.4. I have never loved Core Data, but it has always gotten the job done and proved better than raw SQLite queries (I’m that much of a masochist).

I interviewed the Realm folks way back when on my CocoaRadio podcast and found it to be an interesting project. I just didn’t have anything to implement it in since I was already successfully deploying Core Data in my existing client projects. With a new project that ramped up early last year, I decided to give it a shot.

I’m having a hard time convincing myself to go back to Core Data for anything right now. Core Data has always felt bloated to me, especially when trying to bring up the stack in an application. I also have many battle wounds to show for Core Data threading issues over the years. All things of the past with Realm. I can query the same Realm from any thread and bringing up a new one is at most three lines of code.

Apple is working to improve Core Data each year, but I’m starting to believe they should just reboot the framework like a comic book movie and start over. Or keep it as is, and I’ll keep using Realm.

Aspen

I was a longtime user of CocoaLumberjack, but was running into a issues when starting to migrate an existing client application to use Swift in some places. I also started having issues where there updates to the library would just fail to work in the application without me spending a few hours each release debugging things.

I decided to use that as a chance to write my own clean room logging implementation that does everything I need: which isn’t that much. I call it Aspen, and you probably shouldn’t use it.

It works for me and is deployed on millions of iOS devices, but it’s also something that I don’t really see growing beyond the scope of the project as is. I’d like to add log rolling and ASL support, but after that there’s not much else I need in a logging framework. If your needs are greater, any other solution will probably work better for you.

Fastlane

The newest piece of my kit is Fastlane, a suite of Ruby scripts from Twitter’s development folks. I am using Fastlane to help run unit tests from the command line, build releases and automatically upload them to TestFlight. The suite can do a lot more, but my needs are fairly simple.

The next piece to my Fastlane puzzle will be getting some sort of continuous integration component. Maybe next year.

Plain Old NSURLSession

You’ll notice that I’m not using a networking library like AlamoFire or similar. For most of the projects I am working on, I don’t need the extra overhead those libraries offer me. I tend to put each network request in its own Swift class and make them return an RxSwift Observable. I then have a parent class that will vend those request classes out. I may write about this more in the future, if enough people ask nicely.

Read more about. . .

My Ultimate Developer and Power Users Tool List for OS X (2013 Edition)

This is the fifth installment of my must have must have list of tools and utilities as a Mac and iOS developer (2009, 2010, 2011, 2012). This year’s edition of the list takes into account the new tools I am using as part of my transition to working exclusively on iOS 7 and OS X Mavericks, as well as an amateur designer.

The idea for this list was shamelessly ripped off from Windows developer Scott Hanselman whose list has long been an enjoyable read when he updates it.

Many of the products you will recognize from previous years’ lists. I’ll outline new additions to the list as I go by marking them in bold.

Hardware

My hardware is mostly the same as last year. I am still maintaining a dual Mac setup. My daily driver is a 27″ i7 iMac with a 256GB SSD, 2TB spinning disc and 16GB of RAM. There is absolutely no reason for me to have 16GB of RAM other than to brag about the fact that I have such a ridiculous amount of memory. After almost four years, this machine is still humming along like a champ. The only reason I would consider upgrading to a new one is aesthetics at this point.

At home I am using my 15″ Retina MacBook Pro with a 512GB SSD and 8GB of RAM. This is the first revision of the Retina MacBook Pro and it’s probably one of my favorite Macs ever assembled. My only request going forward is a much higher retina resolution. It’s really a challenge to jump between the massive amount of pixels that a 27″ iMac affords you and then head back to a 1440×900 display at home.

I am using Dropbox more than ever to keep everything between the two machines in sync. I symlink Documents, Downloads, Movies, and Sites to point to those respective directories on Dropbox. I am also using shared Dropbox folders for Second Gear projects that require collaboration with a designer. I’m still using GitHub for storing all of my code.

In terms of accessories and upgrades:

Software

I am really hard on software. This is for a variety of reasons, but I think it is because I build it myself. I have always envisioned that directors and actors can sometimes lose focus during a movie as they judge the decisions others made in their productions. I feel like I do the same thing with software.

I loathe poor and/or non-native user interfaces and cherish simple tools. These are applications I constantly rely on.

The Essential Five

Developer Tools

User Tools

Audio Production

Outside of doing software development, I talk about software development and technology in general with my Windows development buddy, Mikel Berger on IRQ Conflict. These are the tools used to produce the show and some other audio gimmickry I pursue:

Read more about. . .