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

A Software Developer’s Mac Pro

According to the transcript of the chat, Apple has a few different types of pro users it is considering:

  1. Video editors
  2. Music creators
  3. Graphic designers
  4. Scientists
  5. Engineers and Architects
  6. Developers

Developers you say?

Craig Federighi: I think if you use Xcode downloads as a metric, it’s possible software developers are actually our largest pro audience. It’s growing very quickly, its been fantastic.

Sounds like me. I download a lot of Xcode builds. I am important!

I can’t speak to what the other five types of users need, but I have a pretty good idea of what I’d want as an iOS developer who uses a Mac every day. Not that anyone in Cupertino is asking me, but if they did I’d say this is my dream Mac.

Let’s assume that Apple is going to ship this new Mac Pro in 2018. Yes, they are being coy with the semantics of when it will be available (“It won’t ship this year”), but just for this thought exercise, it’ll be on my desk around WWDC 2018.

A Tower of Boredom

Despite the fever dreams podcasters are having about what Phil Schiller meant when he said the new Mac Pro would be “a modular system,” I have no aspirations or desires for a stackable, modular computer where I can add an external GPU or other parts I desire. All I need is a tower that connects to an external monitor. That’s it.

Make it look like the Cheese Grater if you want, or spend time designing something more modern and attractive. If I get a say in size, I’d like something along the size of the Power Mac G4. The Cheese Grater design was nice, but it was also a chore to lug around the few times I needed to move or rearrange my desk.

I think it’s safe to assume there’s no optical drive required in a 2018-era computer, so that should hopefully offer some space and weight savings. I don’t need a micro-ATX architecture. ATX is fine. Just maybe make it not weigh 40 pounds if you can. We are developers, not bodybuilders.


I know Intel has been having trouble of recent years and has taken to tocking more than it’s ticking, but I also don’t see AMD as a viable alternative for CPUs1. Ryzen is interesting, but I’d rather have Kabylake or Cannonlake Xeons.

In terms of speed, the reality is that I haven’t been hamstrung by CPU performance in years. What I need more than faster CPUs is more cores. The trash can Mac Pro got this right. My iMac maxes out at 4-cores. I’m going to want at least 8 for a Mac Pro. Anything more than that seems overkill for me personally, but I can appreciate others might need 12 or more.

What will I use 8 cores for? Parallelizing my compilation in hopes of speeding it up. Well, assuming these Swift performance issues are resolved before you ship this thing.


I know you backed yourself into a thermal corner with the trash can. That’s in the past. All will be forgiven if you just default to using a boring old PCIe video card from Nvidia or AMD. The GTX 1080s are what I have my eyes on for upgrading my PC desktop to. I’d gladly take one in my Mac Pro too.

I don’t need multiple GPUs personally. I’m just a software developer who doesn’t do any game work. I just want to ensure that I have the best GPU I can get when I buy this so that I can ensure that macOS performs as well as it can for a few years. No stuttering when I toggle Mission Control!

And speaking of games, I don’t play them on my Mac. This dream of the Mac ever being a best-of-class gaming platform is long gone. Linux on the Desktop has a better chance of succeeding than I do of getting Overwatch on my Mac day-and-date as PCs and consoles.


I only use SSDs at this point, save for Time Machine. I need the fastest write speeds you can offer me. I’d like to have the ability to mirror my boot drive using RAID for redundancy, but I’ll survive if I can’t.

What I do need though is room for more than a single drive. If you’re going to give me a modular system, I’m going to want to move my Time Machine backup internal and maybe even have separate drives for different virtual machines or operating systems. I’m not doing macOS development right now, but I remember the times of having to boot up an old version of the OS to test or debug a release.

And if one of my drives does fail? I need to be able to replace it quickly, without sending it off to the Memphis repair hub.


I know you all love DDR3, but DDR5 is a thing now. Please? Lots of it. I can get by with 16GB of RAM on my laptop and the world goes on. If I’m going to buy a new tower that I expect to last for several years, I’m going to need at least 64GB of RAM. I’d take more if possible though! I prefer to not think about paging by throwing money at the problem.

What am I using all this RAM for? I don’t necessarily need it for building my app in Xcode, but when you add the virtual machines I run in Parallels for testing, Docker containers, and how the dozens of tabs I keep open at any given time it adds up. Slack also eats memory. I know you aren’t allowed to use it at Apple, but out here in the real world we do and it is a memory hog.


Adapters may be fine for not including Ethernet on a MacBook Pro, but I keep my desktops connected to Ethernet at all times. I need the fastest possible speeds afforded by my Internet connection for downloading and uploading things like Xcode releases, builds to TestFlight, and other bits and bytes I see fit. The current Mac Pro has two. I only use one, but I won’t lose sleep if you give me two.

Please include WiFi for things like Handoff and Airdrop, but don’t take away my Ethernet port for my primary Internet connection. I rely on it on my iMac and I would rely on it for my next Mac Pro as well.

Ports of Connection

I think it’s safe to assume that a developer’s Mac Pro would have the following connections:

I’d like to have a USB-A port or two to connect my wired, clicky keyboard, but I can understand if you don’t want to include them. I’ll add an adapter and never think about it again.

For the ports you do include, I need lots of them. I tend to keep an iPhone, iPad, and Apple Watch connected to my desktop at all times for deploying to via Xcode. I’d hope that without the space constraints of a laptop, every port has the same sort of bus speed. I don’t want to have to think about the upper-left USB-C port being faster than the lower-right one.


Modern Apple is defined by how locked down the system has become. That’s fine for an iMac or MacBook Pro, but I need the ability to swap out a few non-core parts in the future.

If you don’t want to support them via AppleCare, that’s fine. That shouldn’t negate my ability to extend and improve my desktop tower, however.

Everything else

Apple computers are known for being quiet by default. I’m fine with the fans cranking when I’m processing a heavy load, but the default state should be minimal noise.

I know there is a new Apple Pro Display coming, and I’ll likely buy it. Throw a few USB-C ports on the back of it so I don’t have to run long cables from the tower on the ground to my desk. Maybe test it next to a WiFi router before shipping.

I have been using an iMac for the last few years because it seemed like a better option for meeting my needs of wanting a Retina Display with good enough performance. This new Mac Pro has the potential to send me back to Apple’s most niche hardware class. In fact, I’m funneling money away for this new Jesus Computer. I haven’t been this excited about the future of the Mac since the last time Apple said the Mac was back!

  1. Yet. I’m keeping my eyes on you, Ryzen.

Read more about. . .

Why Pro Matters

Sebastiaan de With pens what I consider to be the best argument for why Apple should care about a niche market of Pro Mac users:

Macs became the tool of choice of this new wave of designers, and as the web evolved Apple kept its OS and app ecosystem in sync with its trends; as online video became popular, Apple offered the easiest editing software in iMovie. Blogs and RSS had a peak; Macs came with iWeb that let you author blogs literally out of the box. These designers started to code, or came in contact with developers.

I was there for this, with both G5 and Intel variations of the cheese grater Mac Pro. Before Apple was the largest company in the world, they built the best computers and operating systems for the tastemakers of technology. I never worked with Seb on a project1, but I worked with some of the best designers that have gone on to build the biggest products of the mobile era. We'll ignore that I continue to toil in obscurity, dear reader.

I haven't said much about the Mac Pro's demise because there's plenty of other people with opinions on the hardware. That said, I am glad to see it's no longer on its deathbed. It may not be Apple's most profitable product, but it doesn't need to be. When you have the ability to positively effect the real influencers of the industry2, it's hard to see the downside. I am not sure if the Mac Pro is for me anymore, but I much prefer an Apple that invests at least some of its billions in flexing its computing muscle from time-to-time. Not because it needs to, but because it wants to and can.

(via Pixel Envy)

  1. Someday!

  2. The people that do the work, not just talk about it at tech conferences.

Read more about. . .

Improving the iPad By Making it an iMac

Jason Snell on “improving” iOS for the iPad:

Will we see a 20-plus-inch iOS desktop with a windowed interface anytime soon? I doubt it–but I could imagine one existing in the next three or four years. And I have to be honest, I’d be intrigued by the idea of replacing my 5K iMac with one. It just needs to be able to run a bunch of apps at once, and let me arrange them in a way that works for me.

Tabbed interfaces, multiple windows, and a laptop form factor? If he had just mentioned needing a file system, I would have hit BINGO.

Read more about. . .

The Gang of Four

Scott Galloway:

This is probably one of the most engaging and interesting talks I’ve sat through. If you want to have a really good idea of the size of business the Gang of Four (Facebook, Amazon, Apple, and Google) are doing I doubt you’re going to find a better resource.

There’s so many quotable things in it as well.

On their growth as a media company:

Advertising is becoming a tax only poor people pay.

On generating profits and why Amazon doesn’t:

Profits are heroin to investors. They love them. They get addicted to them. And when you take them away, they get very irritable.

We truly are living in Larry, Mark, Jeff, and Tim’s world.

Read more about. . .