CurrentKey Stats · maker stories

Building my first Swift app, from a background of web app hacking (Part 1)

Quick note/disclaimer: This blog post is from a historically introverted solo hacker, who – aside from personal-use command line tools – has exclusively shipped web app projects until this app.

A long time ago I took a day in the library with my (still shiny new) mid-2011 Macbook Air and poked around Xcode with the intention of getting into app development. Objective-C’s bracket syntax was a pain and Interface Builder seemed too “magical” (why couldn’t everything be laid out programmatically like in HTML/CSS?). By the end of the day, my curiosity had been rerouted to (what were then) hot web technologies, probably Node, Coffeescript, or whatever was being talked about that week on Javascript Jabber.

That perceived friction made a lasting impression, and it wasn’t until I had an idea for a (weekend project) Mac app that I pushed through it. That idea came to me while I was exploring a few different web projects, each split into different Mac desktops (called Spaces). When I opened the lid of my laptop one evening I realized I was shuffling through browser tabs to reorient myself: which Space was I in? Only took a few seconds to find out, but I wanted an instant reference: Each Space should have a unique menubar icon! And a new side project was born. Within a couple of weeks I had a working prototype. (It was months later I decided to add app usage stats and ship it.)

As far as early resources went, a few one off blog posts for beginners really helped, like @Bgreenlee‘s For round-tripping Swift concepts and tricks, I really enjoyed Bob the Developer’s articles I lament that Bob’s writing has stopped, by the looks of it he has been really distracted by crypto. At times, Ray Wenderlich’s site came in handy. A common sense reminder: even tutorial code usually has onerous licensing/copyright terms, so only grok concepts and do your own implementations.

Scavenger hunt driven development

The resources listed above were indispensable in getting basic (but important) things running for the first time in Xcode. However, very quickly I was needing to go deeper than what had been written about on the web.

Online documentation for macOS (AppKit) app development is not much help, largely because of its spread-out nature. However, when accessed from within Xcode, by having the IDE’s autocomplete surface lists of attributes and functions directly on the object of interest, you have a nice way to discover things to tinker with. Sounds simple, but as a web developer who has stuck to text editors like Sublime (which I love), discovering API capabilities in this fashion was actually pretty fun, if slow going.


If you’re a web programmer, you’re in the Wild West. You just are. I’ve been to web dev conferences before, even around specific, opinionated languages like Ruby. Even at those, everyone skins the cat differently. That can be fun for the personal journey, but (for introverted me) it makes it hard to have productive conversations with strangers. So having a common set of tools and experiences actually opened doors here.

Pretty quickly I had found myself at a meetup (WeirdSwiftATX) asking about the trade-offs of the myriad ways to persist data. Everyone at the table had an opinion about each option. Amazing! Early on I also got a great recommendation on charting solutions, Vega.js, and knew I had some locals with whom I could commiserate if need-be. I’m going to give a talk at different meetup in a couple weeks, right around the time of WWDC, should be fun!

Strongly-typed goodness

Although I had played around with Typescript, I’d never built any of my big web projects from soup-to-nuts with strongly typed languages. (I really like/d the pythonistic Coffeescript language, which meant I was trendy in 2013!) Without an extreme level of discipline (which I lack), projects written dynamic languages tend to be hard to refactor (and sometimes just understand after enough time has passed). At a very basic level, Swift’s predisposition toward using structs (and enums) sets you up for being productive in the long run.

My Mac app has passed that threshold in project complexity where I’m SO thankful to have left a trail of well-defined data structures along the way, they’re basically a form of useful (always correct) comments that kill painful type-check bugs. Glorious.

This was the first of a multi-part series on writing my first Swift app. Future parts will cover technical challenges, business model dilemmas, what it’s like launching in the App Store, and experiences from launch day. Thanks for reading! – Spencer