Macs of 2017

The Mac isn't going away. Apple just spent huge resources getting the Touch Bar launched. Resources both on the software side and the hardware side. Both are massive undertakings, I'd like to especially point out the Touch Bar hardware in that it's effectively a tiny iOS computer living and working inside the Mac.

If that's not a vote of confidence for the Mac's future, then nothing is.

The retina MacBook launched in 2015 gave us a small hint at where Apple is taking their notebook line. The MacBook Pros launched late in 2016 offer a clearer look.

Touch Bar improvements:

  • Force Touch is a gimme, in fact I'd be surprised if it wasn't the first improvement rolled out.

Track Pad improvements:

  • I think the larger trackpads are a clear sign that Apple Pencil support is coming to the Mac. Depending on how good Force Touch becomes, the writing surface could become quite reactive to the Pencil input. I'm curious if there will be an adapter sold to charge the pencil from one of the MacBook's USB-C ports.

The Desktop:

  • Mac Pro: CPU improvements have stagnated, I'm not so worried about Apple keeping their Pro devices on the latest Xeons from Intel. Where the Pro needs some love (if it's to continue at all) is in steady GPU updates. If this line is sunsetted I think that would be okay, so long as the "iMac Pro" has a an option for a powerful GPU.
  • iMac: Taking my cue from the MacBook naming in 2015, it might be time to rename the iMac. The new name would be Mac, you're shocked, I can tell. Form factor would be similar to the existing iMac, with smaller bezels.
  • iMac Pro: If I'm right about the renaming, this would be just the "Mac Pro". It would be similar in form factor to the new iMac/Mac (i.e. an all-in-one with a great display). It would have a Xeon processor, ECC RAM, and a beefy GPU from AMD. If we're lucky, it will get regular GPU updates.
  • Mac Mini: Discontinued.

The Notebook:

  • MacBook: Revved with new processors, no Touch Bar.
  • MacBook Pro Escape: No updates, it is now on the MacBook Air track.
  • MacBook Pro: If it's ready, Force Touch Touch Bar.

I wouldn't be surprised if there was a small price drop on the Touch Bar Macs.

Between the Touch Bar and my predicted Apple Pencil support, it's pretty cool that the Mac is potentially about to get two new interface paradigms added to it. That's where the gains are to be made now, not just spec bumps.

These are just my predictions, my reading of the tea leaves.

Developing Seam: Thoughts on Swift

Seam & Swift

I recently released Seam: Relax Your Mind, my first game to the App Store. It's a procedurally generated puzzle game wherein you rotate and snap together puzzle pieces. I have minimal experience writing iOS apps - Seam is a small project, but it's my biggest yet.

Seam is written in Swift and uses Apple's SpriteKit game engine (I'll talk about SpriteKit later). Here are a few things about Swift I think are interesting.

Getting Swifty

The type system: I prefer statically typed languages, especially if there are strict speed requirements (like with a video game). I'd like to specifically highlight the syntax for dealing with types, which is beautifully consistent. This is a subtle thing that I think has a massive impact on a vague feeling ("code feel") that makes reasoning about the typing easier.

// this is an integer
var score: Int = 0

// this is an array of integers
var dailyScores: [Int] = [0, 10, 19]

// this is a function that takes an array of ints and returns an int
func bestDaily(dailyScores: [Int]) -> Int { ... }

// this is a function that takes no args and returns a function
// can you infer the type signature of that function?
func funcMaker() -> (([Int]) -> Int) { ... }

The Swift type system has too many features to discuss in a blog post. It's not perfect though, the type inference fails too frequently. I rely on type inference only in the simplest cases.

Optionals: This might be Stockholm syndrome because there's almost no way to avoid dealing with optionals if you're writing against iOS libraries, but my arc (pun intended) with optionals was "these are annoying" to "these are completely sensible (but still a tiny bit annoying)".

That tiny annoyance is well worth the incredible confidence reasoning against optional values gives you, you check if the value you're interested in manipulating is nil or not, and you're off to the races. It enforces good habits and it gives you a hook to bail out early if something isn't quite set the way you were expecting.

func getUser(_ username: String) -> User? {
    // this function looks for a User by username, it returns
    // an "Optional User" which can either be a valid user or nil

func sendLateFeeNotice(username: String) {
    let user = getUser(username)
    if user == nil {
    // now that we've checked if no user was found, we can now
    // assume our user object is safe to use and manipulate

That's a slightly contrived example but once you get comfortable with using optionals (and if you're not yet, just keep at it, you can do it!) they genuinely inspire confidence in your code. Confidence is a great thing in programming because it clears your head, you don't have to hold as much logical spaghetti in your head, freeing you to think about the problem at hand.

Optionals are not magic though, they reduce the need for some types of error handling but not all. Additionally, there is a feature called optional chaining that allows you to safely drill down a deep data structure and get at the underlying optional - this feature is totally necessary but at times you might see something that looks like this:

let vpOperationsEmail = company?.operations?.vicePresident?.user?.email

This is a very useful feature, but sometimes it looks and feels clunky. As a rule of thumb I think you should avoid force unwrapping basically any long optional chain (using the ! operator) and do your nil check (or use guard) right after.

I could wax poetic about the merits and shortcomings of Swift for a long time, but let me wrap up with one more.

Memory management: Swift uses Automatic Reference Counting (ARC) to manage almost all memory for you. There are some technical implications due to that but for most programmers the biggest will be managing reference cycles using the weak keyword. Thinking about cycles can get tricky if your data structures are complex. On your journey to deeper understanding about reference cycles and why they happen: favor using things passed by value, like enums & structs, which will help you avoid reference cycles entirely.

What is Vulcan?

Vulcan is many things, most famously a planet from Star Trek. While I admire many of the qualities of the fictional Vulcans, their story isn't the one I want to tell, their story isn't the real Vulcan. Let's take a trip.

Newton had done it. He blew the lid off of the galaxy. Gravity, calculus, classical mechanics; he did it, and he gave us the first gaze into the hidden clockwork of the universe. Before, we had but tiny peepholes with muddy lenses, but now humanity could look under the universe's skirt and stare.

Science leapt forward.

Mercury was a problem. We would look up at the bright shiny blobs within our solar system, crunch the numbers, and get a great prediction about when we would see our shiny blobs again. Newton's formulas worked tremendously well for all the planets, except Mercury. Obviously, Newton's Laws worked, they were not the flaw.

To account for Mercury's irregular orbit, some scientists posited the existence of another planet, one we had never seen before. The search was on for the planet Vulcan. Vulcan would have been small, near the sun, and in some sort of groovy gravitational rhythm with Mercury.

They couldn't find it.

Albert Einstein showed we were looking in the wrong place. One of his theory's first great tests was accurately predicting Mercury's orbit. With it, he showed a fundamental flaw in Newton's laws, laws that elsewhere are so accurate. Einstein's theory accounted for an error without upsetting observations of the other planets. With Relativity, one of our greatest scientists eradicated an entire planet, challenged the authority of Newton, and advanced our understanding of the universe.

Not bad.

Vulcan is so near to my heart because its story is the story of science. Predictions are made given our current understanding, when they are not met we must alter our predictions or alter our understanding. Relativity on its own is a masterpiece, it is transcendent because it dances so well with Newton.

But science never really gave up on Vulcan, we're still looking.