I am a spare-time app developer. I have my real job where I manage projects and a bunch of enterprise systems in New York City. But I also build iOS apps for sharing photos and videos under my own brand, Spooky Group — the name reads better on the App Store than it does on LinkedIn. I live about an hour north of the city so most of the coding work I do is on the train.
My premier app is wevew, pronounced “we view”. wevew shares photos to nearby iPhones and iPads through a secure live session. When you pan and zoom, my screen pans and zooms. So you can send me your photo and show me the bit that you want to talk about. We can share our photos without sharing our phones. It took about 5 months, but I recently completed a big update which adds video sharing. You can now share videos and play them in sync.
Since I’m working by myself, I don’t do classic sprints because I can’t define a specific timeframe for releases. I plan a group of related features as a package and work through the backlog until I feel it’s ready. When that time comes, I have a whole plan that works based upon Apple’s process for reviewing apps. If you are unfamiliar how Apple does this, here’s a quick look.
Apple’s system for managing third party apps is called iTunesConnect. All of the info about your app (name, description, price) and each version (the number and those ever entertaining release notes) is entered in the iTunesConnect website. Then using Apple’s development tool Xcode, you build your app into a single file called an archive and upload it. As the archive is uploaded, it’s checked to ensure it conforms to Apple’s developer policies. Once the upload completes, the build is sent through another round of checks. There are many things that can stop you at this point, but if you and all of your open source libraries are playing by the rules, you usually pass this validation too.
Your app is assigned a state as it progresses. While we have been uploading, the state has been “Prepare for Submission.” Where you want to be is “Ready for Sale,” where your app is on the App Store and people can find it and buy it. When the second validation pass completes, you get an email saying the build is ready. Going back to iTunesConnect, you select the build, assign it to a version, and save it. You are ready to submit.
For me, the Submit button has always been a source of joy and anxiety. The whole point of building apps comes down to this moment. But is it ready? Did I missing something obvious? Does this version crash and kill all of the momentum built up to this point? Click Submit and, anticlimactically, Apple asks a two more questions related to encryption and ad tokens. Submit that and your state changes to “Waiting for Review.”
My first submission through iTunesConnect was three years ago. Good turnaround time to approval was about 1 week. Worst case was nearly 3 weeks. That time it was so long that I sent a message asking if I had been added to some kind of “developer watch list.” I wasn’t. There was just a huge backlog of apps in front of me waiting for approval.
Approval time is broken into two stages: “Waiting for Review” and “In Review” when someone from Apple is actively testing and checking your app. During both stages, you can to make changes to your app’s meta data: the description, release notes, and the images that appear on the App Store. You cannot change the name of your app, but pretty much everything else is available. I learned that this is valuable time. After focusing entirely on the product, I found I could spend “Waiting for Review” working on the marketing content. The gap was so long, that I found I could even take a break for a couple days before starting that work. And that was fine, until this past May.
It was Sunday, about 2:30pm. I submitted wevew version 3 for review. Along with video sharing it has an entirely new user interface. I would need to redo of all of the App Store graphics. Apple gives you 5 images on the App Store to sell your app. At the time, each device, by its size, needed a uniquely sized image: 3.5” iPhone, 4” iPhone, 5.5” iPhone, iPad, etc. — 30 images to be assembled. You can also provide a 30 second video preview, but I haven’t managed to do that yet. Since this was a big release, I wanted to do a lot of website and promotion materials. There would be no break this time. I started the graphics work that evening.
On Monday at 1:30pm, I received a message from iTunesConnect stating the app was “In Review.” I thought it was a mistake. I checked it a couple times. It was less than 24 hours. No mistake. I was not ready.
Like any reasonable person, I consulted The Google. Turns out, Apple has made some major improvements to its approval process. AppReviewTimes.com, which tracks review times through user submissions, shows average approvals are below 3 days. Bloomberg reports “Apple Shortens App Review Times in Push to Boost Service Sales.” The New York Times is also reporting that this is one of several changes Phil Schiller has made since taking ownership of the App Store.
Ugh. First I had to accept that my big 3.0 release was going to hit the App Store with version 2 graphics. I could pull the release until the graphics were ready, but I really wanted it out. So Monday night, I did what I could and rewrote the content for the App Store. Graphics work would continue on Tuesday morning.
The app was approved and ready for sale on Tuesday at 10:45AM — 44 hours and 15 minutes from submission. Graphics were nowhere near done. I finished the graphics work on Wednesday night.
In order to release v3, I shredded my backlog. Everything that wasn’t absolutely necessary would be shifted to 3.1 or 4.0. Now with one day of real users on the app, I could see reports of a couple crashes. I started planning v3.1 and added these to the backlog.
Turns out the crashes were all quick hits. Instead of folding these into 3.1, I would push an update right away. Within two hours on Thursday I was able to fix the crashes and add one quick feature — press and hold on the video player to play or pause — this makes it easier to work with really short videos. V3.0.2 was submitted to Apple at 8:50PM Thursday. It moved to “In Review” on Friday at 2:30 PM.
If you follow app updates, you’ll see that we have all baked the approval time into our development cycles. Facebook releases all of their apps on a two week schedule. I imagine that their code hitting the App Store today was written about 6 weeks ago. 4 weeks ago it entered testing. Two weeks ago it was submitted for Apple review. It has enabled them to deliver continuous improvements while isolating itself from the fluctuations of the approval process. I don’t think that’s going to change, but going forward the code that hits the App Store will probably only be about 4 weeks old.
With a 7 day approval cycle, you better be really sure that app will pass review. With 2 day approvals, I’m not so certain. Most teams do two week sprints, while lots of other teams do one week sprints. For me, working on the train, I could do one hour sprints. Build a feature on the train to NYC. Test on the evening train home. Build and submit that evening. I assume version 3.0.2 will release on Saturday. If I submit version 3.0.3 on Saturday night it could release on Monday. Following that, version 3.0.4 could release the next Thursday. Not to say that this would work for every release, but it provides a powerful new option for me.
wevew 3.0.2 released on Friday May 13, 2016 at 10:53 PM. Time for approval: 26 hours, 3 minutes.
wevew 3.0.3 released on Thursday May 27, 2016 at 6:35 PM. Time for approval: 19 hours, 1 minute.
Update: Since I wrote this, approvals have slowed a little bit, but Apple made a significant change to their search algorithm. Starting September 1, app names must be 50 characters or less. They are also undertaking a program to clean the App Store of old apps. Next post will cover the challenges of new rules for App Search Optimization and how that impacts the spare time, independent developer.