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?”
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.
- 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. ↩
- 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. ↩
- Given the end of the original TestFlight, that proved to be a good use of time. ↩