Can Apple Fix the Universal Negativity Toward iTunes Connect App Reviews?

Why is it that everyone we talk to who has ever developed iOS apps cringes when you say, "My app is in review." We feel the same pukey feeling in our guts when our app is "Waiting for Review" or "In Review."

Dear Apple: any time that hundreds of thousands of developers all feel the same negativity towards something, it seems like it's something you could maybe look at fixing?!? I fully agree with the idea that your quality control makes the iTunes App Store a much better experience than all the other app stores out there. That said, I think you could improve the experience of having apps reviewed and still maintain the high level of quality.

Here are my thoughts for how you could make the process better:

1. Tell us how many apps are in front of us.  Let us see them being counted down.  Progress bars help people feel patient because they know how much is left.
2. Be transparent about average review times. It's OK to put all your disclaimers out there about all apps being different, not having guarantees on time, etc. but it's nice to know how long things are taking now.  The fact that http://appreviewtimes.com/ exists and gets tons of traffic means you're not being transparent enough with your information.  We know you track the average review time.  Share it, and developers will know what to expect.
3. Have more consistency with your reviewers. At lunch today, we were joking with some developers from another local company about how you never know what you're going to get--it depends on the mood of the reviewer, the alignment of the stars, and the price of tea in China. This one is easy to suggest and hard to implement.
4. Have a TSA Pre-check. I can't believe I'm going to say that you should do something that the government is doing, but that's how bad the experience is right now.  Allow developers that have had several clean reviews in a row to automatically go through an expedited line, where the reviewer can be a little bit less thorough.  If you need to do a follow-up, consider a two-stage review where you allow the app to be sold while the second stage is waiting for review.

Step 4 - Functionality

This post is part 3 of a 4 part follow-up to my post: Market, Marketing, Aesthetics, then Functionality.  Remember, before doing this last step, entrepreneurial developers need to really focus on the other steps. Once you've adequately covered Market, Marketing, and Aesthetics, it's finally time to focus on

Functionality

For developers, this one tends to come much more naturally than the first three.  Here are a few things that were helpful to us as we worked on the features and functionality of Name Shark (http://namesharkapp.com):

CocoaPods

From http://cocoapods.org/:

CocoaPods is the dependency manager for Objective-C projects. It has thousands of libraries and can help you scale your projects elegantly.

This is by far the most useful tool that we have used for development.  There are thousands of open source tools built by developers to use in your project.  Most of them have very friendly licenses that can easily be used in a commercial project.

Here's the current list of pods that we use in Name Shark:

pod 'CTCustomTableViewCell', '~> 2'
pod 'StackBluriOS'
pod 'UIImage+ImageWithColor'
pod 'OCLogTemplate', '~> 1.0'
pod 'FontAwesomeKit/IonIcons'
pod 'FontAwesomeKit/FontAwesome'
pod 'TPKeyboardAvoiding', '~> 1.2'
pod 'RandomSequence'
pod 'AWSiOSSDKv2', '~> 2.0'
pod 'RPFloatingPlaceholders', '~> 0.2'
pod 'REMenu', '~> 1.9'
pod 'Facebook-iOS-SDK', '~> 3.15'
pod 'JFBCrypt', '~> 0.1'
pod 'UIAlertView+Blocks', '~> 0.8'
pod 'UITextField-Blocks', '~> 1.0'
pod 'UIActionSheet-Blocks', '~> 1.0'
pod 'MZFormSheetController', '~> 2.3'
pod 'UIImage-Resize', '~> 1.0'
pod 'NSDate+TimeAgo', '~> 1.0'
pod 'LLACircularProgressView'
pod 'FlurrySDK'
pod 'iRate', '~> 1.10'

We are very grateful to the pod creators for these very helpful tools.  We highly recommend taking a look at these and other pods for use in your app.

Parse

With *AAS (Everything As A Service), it really doesn't make sense for app developers to build their own backends.  We investigated several Mobile Backend As A Service (MBAAS) or Platform As A Service (PAAS) or just Mobile Platform providers, and settled on using Parse (http://www.parse.com).

Parse has very nice iOS native integration.  They take care of the database in the cloud, user authentication, user rights management, cloud syncing, etc.  We did end up having to use AWS (Amazon Web Services) for storage because Parse has a 10 MB per file limit on their files.  And, although Parse's storage rates are slightly better than we could get on AWS, file access counts towards your requests per second.  We found that using these two in combination worked nicely.

(Russ will post a follow-up on how to create a federated user in cloud code so that you can have correct rights with AWS and Parse.)

Parse's pricing model is fairly simple.  You actually get to start for free, up 30 requests per second, 20 GB storage, 20 GB database, 2 TB transfer, and 1 concurrent background job.  From there, the pricing goes up.

We figured out the bandwidth usage, storage, and number of requests for an average user, and we should be able to make a decent profit by showing ads or by having users pay to remove them.

Flurry

Analytics are critical to understand what your users are doing in your app.  We used Flurry back when we did Tiki Kaboom (http://tikikaboom.com), and we found it to be extremely helpful.  There are many analytics providers, but we have lots of experience with Flurry, and we are pleased with the improvements they continue to make and features they continue to add.

Product Functionality

We worked very hard to try to make the user experience intuitive and friendly.  We tried to minimize clicks for user interaction.  We picked defaults that could easily be changed.  We have implemented, listened to our internal Beta users, changed things, listened some more, and changed things again.

We intend to use feedback from every source we can find to make our product better.  This first version is only the first stab.  I really like Guy Kawasaki's thoughts on shipping and fixing:

Don't worry, be crappy. An innovator doesn't worry about shipping an innovative product with elements of crappiness if it's truly innovative. The first permutation of a innovation is seldom perfect--Macintosh, for example, didn't have software (thanks to me), a hard disk (it wouldn't matter with no software anyway), slots, and color. If a company waits--for example, the engineers convince management to add more features--until everything is perfect, it will never ship, and the market will pass it by.

Churn, baby, churn. I'm saying it's okay to ship crap--I'm not saying that it's okay to stay crappy. A company must improve version 1.0 and create version 1.1, 1.2, ... 2.0. This is a difficult lesson to learn because it's so hard to ship an innovation; therefore, the last thing employees want to deal with is complaints about their perfect baby. Innovation is not an event. It's a process.
-http://blog.guykawasaki.com/2006/01/the_art_of_inno.html

◀   Step 3 - Aesthetics

iTunes Connect Expedited Review

Name Shark (http://namesharkapp.com) is still sitting in the state of "Metadata Rejected" four days after we resubmitted the metadata.  Beginning to get nervous, I submitted a request for expedited review.  We are presenting at 1 Million Cups Provo on Wednesday, November 5th, and it's pretty important that we have a version for attendees to download on that day so we can get their feedback.

Requesting an Expedited Review

Here's how we requested an expedited review (from App Review - Support):

Here is the form to make the request: https://developer.apple.com/appstore/contact/?topic=expedite (you must be logged in with you iOS developer account.)

The form looks like this:

My understanding is that you need to have a good reason.

Take note that you will, "Select the reason you are requesting an expedited app review."  Then you, "Provide a detailed explanation of the reason you selected." Apple warns that, "Your request may be denied if you do not provide sufficient details."  My understanding is that they really do need a good reason with supporting details.

In our case, we do have an event where we are the presenters, and we'll be talking primarily about the app that hasn't been approved yet.

Notification of Approval or Rejection

We submitted this request on Friday at 4:00 PM PT.  On Monday at 11:25 AM PST, I received the following email from "App Review (do_not_reply@apple.com)"

Hello Benjamin Larson,

Thank you for contacting App Store Review to request an expedited review. We have made a one-time exception and will proceed with an expedited review of Name Shark.

We understand that situations can arise which require more immediate attention and have developed the Expedited Review Process for such situations. We want to remind you that expedited reviews cannot be guaranteed and are provided on a limited basis. Therefore, we may not be able to accommodate additional requests in the future.

If your app is rejected during this review, it is not necessary to request another Expedited Review when you resubmit. Once you revise and resubmit your binary (or metadata, in the case of a Metadata Rejection), your app will be automatically returned to the expedite queue.

Best Regards,

App Store Review

Expedited Review Queue Wait Time

At 5:58 PST, the status on our app changed to "In Review".  At 7:03 PM PST the status changed to "Pending Developer Release" because we marked that we wanted to release it manually.  This means it is approved!  Finally!

So, for us the Expedited Review Queue wait time was approximately 7 1/2 hours.

The whole process since requesting an Expedited Review took just over 3 days.  I suspect it would have been shorter if we hadn't requested the review on Friday at 4:00 PM.  I read that they only approve the Expedited Reviews M-F during work hours, but the actual reviews go all weekend and at nights.