Or: The Epic Saga of Shipping an Update to a Legacy App Largely Untouched Since 2012.
Here’s how and why I created Snip*, how I shipped one feature update and subsequently neglected the app for 2½ years, how I fast-forwarded an old codebase into the present — and 7 lessons that I gleaned from the experience:
October 2012
I had just gotten back to Frankfurt after an immersive 3 months in New York, where I decided that I want to go freelance as an iOS app developer.
I had no idea how to find clients. (I applied to jobs on friggin’ Elance, a freelancer platform where I found myself constantly competing with $10/hour freelancers in other parts of the world. Not worth the time to write the proposals.)
And I had no network. (Although I had worked here as an iOS developer before moving to New York, I, like many other tech and creative types in Frankfurt, didn’t venture out of my company’s cocoon very much. Also, there was maybe one relevant meetup happening per month.)
So, in the month that it took to land my first freelance gig (a challenging 3-month project with YCombinator alum Nicolas Bös), I built a simple note-taking app to teach myself about Core Data and asynchronous processing with GCD for buttery-smooth interactions. The app let users compose text, photo and voice snippets into documents. That app was Snip*.
(Snip* App Store screenshots from 2012)
As you can see, I was riding the early wave of “flat” design. I even invented the chevron Back button before Apple adopted it in iOS 7! ;-)
I released Snip* into the App Store at an “introductory price” of $0.99. My whole launch strategy consisted of announcing it in this blog telling my friends about it. It was, after all, essentially a practice app. Snip* got picked up by Apple as New & Noteworthy, and I got a modest number of sales.
Lesson #1: Learn something new, use it to make something, and ship it.
(Side note: I originally called the app “Snipster”, but changed it to “Snip” after the owner of a music app complained that I was using their name.)*
June 2013
I kept getting the same feature request from a couple of users. So I added a simple Export feature that let users to export their snippet documents as an e-mail.
My few but surprisingly dedicated users rewarded the new Export feature with over-the-top reviews. (“OK this is the big hit … really good!” —papapapu)
Lesson #2: Listen to your paying customers. When people start asking for the same features, they might be useful to others, too.
Also, for this update, I decided to try out the up-and-coming UI design app Sketch. I used it to re-create and polish the icons (which I had botched together quick and dirty for v1.0), and found that Sketch fit my mental model of designing much better than Photoshop or Acorn.
Voice-snippet icon, recreated in Sketch
Lesson #3: It doesn’t need to be perfect to be useful. Don’t use perfectionism as an excuse to not ship.
2014
In 2014, I was busy building Gemba, a Mac app for dragging-and-dropping assets into Git repositories, and pivoting from iOS development to UX design at Bontouch in Stockholm, and I didn’t touch Snip* at all.
I briefly experimented with $0.99 and $4.99 price points to see whether that might affect downloads significantly. I ended up at $2.99, positioning Snip* as a premium, robust, no-nonsense app for mixed-media notetaking.
2015
I considered giving Snip* an overhaul out of mere vanity: I felt ashamed of having such an old app to my name on the App Store.
Busy with redesigning core parts of the flinc ride-sharing app’s user experience, as well as running experimenting on my Gemba app business, I ignored my shame and did not touch Snip*. All the while, Snip* sales continued to trickle in, almost exclusively from Germany.
Lesson #4: Build assets. They let you capture value over time.
Aside from a glowing 4-star review (entitled “Function vs Aesthetics”, and proclaiming that a “Redesign would make the app the best of its category”), people didn’t really seem to mind that the app was technically from the stone age of iOS.
Even more gratifyingly, it seemed that people were finding Snip* to be genuinely useful for their work! (“I use it at work and when assembling parts. To create documentation of everything.” —Anonyml)
I think there might also be a lesson in the fact that many of my sales of this app have come from Germany:
Lesson #5: People trust other users’ reviews. Happy users showing genuine enthusiasm is key.
January 2016
While I was in Lisbon for a few days to do my annual personal review/retrospective/kickoff, I got another feature request. Alex, who works at a furniture retailer and was using Snip* for documenting the delivery of incoming goods, requested a minor change in how the e-mail export was structured.
This should be simple enough, I thought, so I promised Alex that I’d look into it.
Turns out, with a 3-year-old code base, nothing is simple: The Xcode project (using the antique Forstallesque iOS SDK version 6) didn’t build, the analytics library had become unusable, when I did somehow get it to compile, it spewed warnings everywhere, and I got crashes when trying to record a voice snippet.
Outsourcing Modernization
After one hour of trying to fix this mess, I remembered Elance, the platform where I had tried to find my first freelance gigs while I built Snip*, in October 2012. Since then, I had started using Elance as a client, outsourcing small programming and research tasks to freelancers abroad. I decided to find a freelancer who would do the work for me.
Elance had me first migrate my account to Upwork (the merged platform of Elance and Odesk, a very similar platform). To my astonishment and relief, the account migration worked flawlessly.
Here’s the project brief that I posted on Upwork:
Modernize legacy codebase of small iOS app (3.000 LoC from 2012)
I have a simple iOS app that I wrote in 2012. It was built on SDK 6 and has just 3.000 lines of code. I want you to modernize the codebase, notably:
(1) infrastructure:
- build with latest SDK (iOS 9.x)
- target iOS 8
- remove Google Analytics tracking
- fix compiler errors and warnings
- modernize project settings
- convert to Swift
(2) in source code:
- fix layout glitches due to UIViewController changes (topLayoutGuide etc)
- remove custom back buttons and just use standard back buttons (I “invented” chevron back buttons before Apple “stole” them for iOS 7 ;-)
- make the app work just as well as the current version (the one that is built with iOS 6 SDK), i.e. no new bugs
- fix any other weirdness that you come across – bonus payment possible!
I will provide you with the full source code of my app, as well as a promo code so you can download the existing app.
You MAY use this project as a portfolio reference. You may NOT redistribute the source code and may NOT use the source code for any other purpose that for this project.
I am open to paying a bonus for exceptional work, as well as hiring you again for similar projects in the future.
Within a half day, I got 3 applications that were within my (ridiculously low) budget. All in all, it took me an hour to write the brief, choose from the 3 offers, pay the agreed price into escrow, and make available the source code to my freelance iOS developer from Russia.
Over the course of the week, she kept me updated and asked for my input whenever she felt there were two viable alternatives. By the time of the deadline, the code base was clean and modernized, fully converted into Swift, and compiled without any hiccups. I was happy with her work and impressed by her professionalism. (I paid her a bonus.)
Lesson #6: It is sometimes useful to outsource development work, even as a developer.
App Store Review
I fixed some minor issues, added the feature that Alex had requested (2 lines of code), prepared updated screenshots, and submitted version 1.4 to the App Store.
After 4 days, it was promptly rejected, with the puzzling explanation that “Your app is too similar to Siri, which creates a misleading association with Apple products.”
Huh?
The App Store reviewer helpfully included this screenshot:
So, apparently, they were taking offense at me using a generic microphone icon, which in their mind too closely resembled the Siri microphone. I disagreed, so I wrote this in reply:
Dear reviewer,
I have used my microphone icon ever since the first version of the app, released in October 2012, before Apple launched Siri. I have no intention of associating the app with Siri, nor do I think users will confuse my app with Siri.
The Siri icon is much taller/slimmer than my mine. I am using a generic microphone icon that is used in a widespread number of apps: https://encrypted.google.com/search?hl=en&q=microphone%20icon
I kindly ask that you reconsider the rejection.
Should you maintain that my icon is too similar to Siri, please advise: Are microphones generally out of the question? What amount of variation would make the icon acceptable?
[4 sample variations, linked and attached]
Please advise. Thank you for your consideration, Yang
After another 2 days, the reviewer graciously accepted my point of view and flagged Snip* through.
Lesson #7: App Store reviewers are reasonable people. If you believe you’re in the right, don’t be afraid to make your case. (But do accept that it’s ultimately their call.)
Snip*, 2016 edition
Whew… you’ve read this far! :) Now, to end this epic post:
After more than two-and-a-half years, an updated version of Snip* is finally Ready for Sale! If you’re interested, check it out on the App Store. To celebrate the update, Snip* is only $1.99 for the next few days.
Let me know what you think about Snip*, and also about this blog post.
I’m @yangmeyer on Twitter.