When the App Store first launched, mere presence was enough to ensure at least some small amount of success. Today, things are much different. A great idea with good execution will still struggle to make a splash in the App Store, unless the stars are perfectly aligned. Even then, it’s usually more about who you know and the press you can drum up.

Here’s a conversation I had with Kevin Harwood last week:

Kevin: “How was the [Pactola] launch?”

Me: “Eh… I knew it was going to be light. It’s pretty niche.”

Kevin: “Friends and family?”

Me: “Yep.”

I wasn’t kidding; I knew full-well going into the project that I was going to have a hard time selling an application that provides a rest API for sending push notifications. There are similar free apps, and the target market is pretty specific. To make matters worse, I spent no time marketing or reaching out to press folks who might want to do a review. These are pretty basic things, right? You’re probably asking why I bothered to build the app.

Here’s a secret for anybody interested in iOS development: employers don’t care how many units you’ve sold on the App Store. They care about what you’ve built: how you did it, what you learned, the extra attention to detail you gave, and how all of those things can help their team.

So why did I build Pactola?

  • The server is built in Go. This was my first experience with the language.
  • Jenkins deploys the server automatically when I push to master. The iOS build is also on Jenkins to ensure I’m building from reproducible sources, and not just a point-in-time on my local workstation.
  • The deployment script relies only on SSH and bash, minimizing VPS setup time and overall dependencies.[1]
  • The iOS app uses Storyboards and Auto Layout (I’m coming off of two years where I was primarily focused on OS X development targeting 10.6 and up; no ARC, no Auto Layout, and no Storyboards)
  • Screenshots are automated, thanks to ui-screen-shooter. I had to learn about UI Automation and come up with a strategy for creating real data in the screenshots.[2]
  • I disciplined myself to write out tasks and issues, and then tracked them on a Trello board. When the tickets were all in the Done column, I shipped. I also have a nice backlog of future ideas and nitpicks.
  • I used Apple’s TestFlight system for the beta. This was my first chance to use it, and I got a good feel for how it compares to the legacy TestFlight system.[3]
  • I’ve now shipped an application that uses APNS and have a strong working knowledge of the system, its capabilities, and have some ideas for leveraging it in other apps.
  • I tried to stick to a Ninety Days rule, though I didn’t account for changing jobs.

So while I may not ship very many copies of Pactola, I’d say there are a few interesting things I could talk about in an interview. I’d highly recommend finding something you’re unfamiliar with and building your own Friends and Family app.

  1. Since Go apps are statically linked, there are no other dependencies on the host system; pactola-server runs on any Linux system once my keys are there to accept the ssh deployment. ↩︎

  2. The app contains no extra magic for this, except for registering as a special known-device when running on the simulator. The server populates the data for that special device. And yes, there are Go tests for that special behavior. ↩︎

  3. Given the end of the original TestFlight, that proved to be a good use of time. ↩︎