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.

Metadata Rejected

Argh!

Day 15 - Rejected again.  We got the following email from iTunesConnect App Review:

Hello Benjamin,
Your app Name Shark has been reviewed, but we are unable to post this version. For details, or to directly contact the App Review team, visit the Resolution Center in iTunes Connect. Do not reply to this email.
Regards,
App Review

We logged into iTunesConnect, and found our app status was

Metadata Rejected

Upon visiting the Resolution Center, we learned the following:

Reasons

• 3.14: App previews may only use video screen captures of the app, voice-overs, and textual and design overlays, or the app will be rejected
• Information Needed

----- 3.14 -----

Your App Previews include content that does not sufficiently reflect the app in use, which does not comply with the App Store Review Guidelines.

Specifically, your previews still displayed other apps. It is necessary to remove this content from your previews.

Also, your app still did not display any ads during the review. Please provide us with access to a video that demonstrates the ads shown in your app.

To provide a link to a demo video:

- Log in to iTunes Connect
- Click on “My Apps”
- Select your app
- Scroll down to “App Review Information”
- Provide demo video access details in the “Notes” section
- Click Save
- Click Submit for Review

Once this information is available, we can continue your review.

This was extremely disappointing.  We were rejected for the same two things we were rejected for the first time, and we thought we fixed the one that was actually wrong.

Issue #1 - App Preview

The only thing we can think they mean when they say, "your previews still displayed other apps," is that we show the home screen with app icons when we show our app launching.  If that is what it was, it's pretty frustrating.

The part we suspect is the first 2 seconds.  We already changed out the twirling iPhone at the end of this one:

Developers take note! No matter how much you like your icon, you can't show it in your App Preview!

We are having the guys at Mango Creative give us a new version that starts at the splash screen.

Issue #2 - Information Needed about Ads

The reviewer said, "your app still did not display any ads during the review."  We looked at our Flurry logs, and found that the reviewer logged in as the same user as last time, despite our specific instructions to create a new user if they wanted to see the ads.

They asked us to provide video that demonstrates the ads shown in our app and gave us instructions on how to do that.

I'm kind of bugged by the lack of effort shown by the reviewer to follow the instructions we submitted, but at least he/she provided an easy way for us to solve the problem.

We'll upload the new App Preview and the Video showing the ads tonight and then resubmit.  Fortunately, this state -- Metadata Rejected -- shouldn't need a new binary.  I'm hopeful that means that the next iteration of the process is quicker than 8 days.

Step 3 - Aesthetics

This post is part 3 of a 4 part follow-up to my post: Market, Marketing, Aesthetics, then Functionality.  Before coding features, entrepreneurial developers need to nail down three essentials. The third of these is

Aesthetics

Programmers typically do a very poor job with this one.  My former co-founder and CEO of Imagine Learning often said, "Why is it that programmers love 8 point fonts?  They need to be big enough for people like me to read!"

I think the answer is simple.  Programmers like to code features.  If the IDE provides a drag and drop way for me to add widgets to my app, then the default font faces and sizes are good enough for me.  And what was the default font for controls in Visual Studio in the days that programmers were learning to do UI?  8 pt Tahoma.

Startup programmers need to be much better at design.  If you are sure you can't be good at it, then hire someone to do it for you.  The default controls and style are just not going to cut it.

If you're going to give it a go yourself, here are some resources that we used:

Behance

Start by searching Adobe Behance for projects that you like. (Using the search term "UI/UX" will net some good app design results.) Note about what you like about each design.  I created categories for color and fonts, flat design, icons, etc.  You can see my collections here: https://www.behance.net/BJamUT/collections.

I found that several of the designs I liked were done by the same artists.  I started following several artists, and I get updates when they post new projects.  This keeps me up to date on what's trending in app design.

color.adobe.com

Formerly kuler.adobe.com, this site has been a favorite of mine for years.  With this site you can experiment with different colors to determine an attractive color palette for your app.  We explored thousands of themes before settling on a couple that we liked and then we modified them slightly.  Here are the two themes we used for Name Shark:

Name Shark

Contrasting Monochrome

At the time of writing, the color palettes above look really familiar to the reader.  :)  Note how we have used the colors throughout the app:

Fonts

As is apparent above, we really liked thin sans-serif fonts.  We settled on Helvetica Neue Thin, which was installed on Mac by default:

We wanted to use a similar font for our web fonts, and if you're looking for a nice, free alternative for multi-platform use, there are two fonts that we really liked on Google Fonts:

http://www.google.com/fonts/specimen/Roboto

and

https://www.google.com/fonts/specimen/Source+Sans+Pro

One final note on fonts: Make them big!  Users like to see the text.  If you can't fit the text on the screen, you're probably trying to put too much information on one page.

Icons

If you've made it this far through the page, I'm about to give you the best gem on this page: FontAwesomeKit.  Available as a CocoaPods pod:

pod 'FontAwesomeKit', '~> 2.1'

FontAwesomeKit allows developers to use thousands of royalty-free icons that are vector format cleverly embedded into a scalable-vector format that was being used long before adoption of svg or pdf: fonts.  Developers don't have to have Adobe Illustrator skills or create multiple versions for different sized icons.  These font-based icons are added in code and they scale automatically.

We like this particular pod because, like other pods, it contains the FontAwesome icon font.  In addition, it contains several other fonts--our favorite being ionicons.

About 75% of the icons in our app are from FontAwesomeKit.  We did have to make some of our own icons to match the thin style of the iOS 7 icons in ionicons.  For those we used Adobe Illustrator, and it happens that I have had some experience using Illustrator previously.

Even if you are not familiar with Illustrator or icon design, your app can look very clean, professional, and impressive by using FontAwesomeKit.

And here's the result of our focus on aesthetics prior to developing Name Shark:

◀   Step 2 - Marketing   |   Step 4 - Functionality   ▶

Step 2 - Marketing

This step is where Russ and I are admittedly the weakest. We have been programmers, managers, executives, board members, but we have always left most of what would be traditionally called marketing to very talented people who have marketing skills. That said, if we are ever going to make an indie app development company work, we have to become really good at marketing.

Since we don't know much about it, we spent a few days studying what people are doing out there. I should mention at this point that our absolute favorite business book is Rework by Jason Fried and David Heinemeier Hansson.  The chapters in the PROMOTION section (pages 165-198) are a must-read, and a basis for our marketing efforts.  Here is one of my favorite quotes from this section:

Marketing is not a department
Do you have a marketing department? If not, good...Accounting is a department. Marketing isn't. Marketing is something everyone in your company is doing 24/7/365.

• Every time you answer the phone, it's marketing.
• Every time you send an e-mail, it's marketing.
• Every time someone uses your product, it's marketing.
• Every word you write on your Web site is marketing.
• If you build software, every error message is marketing.
• If you're in the restaurant business, the after-dinner mint is marketing.
• If you're in the retail business, the checkout counter is marketing.
• If you're in a service business, your invoice is marketing.

Recognize that all of these little things are more important than choosing which piece of swag to throw into a conference goodie bag.  Marketing isn't just a few individual events.  It's the sum total of everything you do.  -Rework by Jason Fried and David Heinemeier Hansson pages 193-194.

So, we figured that everything we did needed to be marketing.  We had already identified who we would be marketing to (see Step 1 - Market).  Now we needed to figure out how we would help them to individually know about the product.

Here's our preliminary list of marketing strategies we plan to chase to help our target users know about Name Shark:

• Try to get reviewers to review our app
• Update our website, landing page, and blog (check)
• Contract with a search enginge optimization (SEO) guru.  Choose niches specific to our target user profiles.
• Banner advertisements on trade sites targeted at user profiles (e.g. sales people, CEOs, event planners, sports fans, etc.)
• Submit to Product Hunt
• Submit to Show HN (Show Hacker News)
• Facebook hype (to our friends)
• Ask friends to post about it on social media
• Reach out to companies/individuals that created services/tools/pods/APIs that we used and ask them to feature us
• Give tips to local newspapers about "local entrepreneurs"
• Niche magazine ads (again for the specific user profiles)
• Adwords
• YouTube advertising (contract Mango Creative to do some humorous and emotional videos for us)
• 1 Million Cups - meet with others and ask them what they did.  Maybe present there.
• T-shirts

One quick thought on t-shirts: we saw a post on Hacker News about a guy who wears a t-shirt or polo with his logo on it every day--everywhere he goes.  This fits in really well with the idea that, "Everything You Do Is Marketing."  We have been doing this, and we get asked almost every day, "What is Awesome Geekness?" or "What is Name Shark?"  Wearing logo shirts provides you with lots of opportunities to verbally sell your product everywhere you go.

◀   Step 1 - Market   |   Step 3 - Aesthetics   ▶

Rejected!

Nine days after submission, we received an email stating

"Hello Benjamin,
Your app Name Shark has been reviewed, but we are unable to post this version. For details, or to directly contact the App Review team, visit the Resolution Center in iTunes Connect. Do not reply to this email.
Regards,
App Review"

After visiting iTunesConnect and clicking on the link to the Resolution Center, here is the text on why the app was rejected:

Reason #1 - App Preview

--------Begin---------

Reasons

3.14: App previews may only use video screen captures of the app, voice-overs, and textual and design overlays, or the app will be rejected

Program License Agreement

----- 3.14 -----

Your App Previews include content that does not sufficiently reflect the app in use, which does not comply with the App Store Review Guidelines.

Specifically, your previews:

- Included device images and/or device frames. 

- Displayed other apps.

It is necessary to remove this content from your previews.

---------End---------

Apparently Apple is pretty strict with the enforcement of this guideline.  The only place we showed devices was in the outro of the video.  See the original version of our Name Shark iOS App Preview video here:

It was just the spinning iPhone at the end of the video.  We have asked the guys over at Mango Creative to change the outro of the video so we can resubmit.

Reason #2 - Ad Identifier

--------Begin---------

PLA 3.3.12

Additionally, we found that your app uses the iOS Advertising Identifier but does not include ad functionality. This does not comply with the terms of the iOS Developer Program License Agreement, as required by the App Store Review Guidelines.

Specifically, section 3.3.12 of the iOS Developer Program License Agreement states:

"You and Your Applications (and any third party with whom you have contracted to serve advertising) may use the Advertising Identifier, and any information obtained through the use of the Advertising Identifier, only for the purpose of serving advertising. If a user resets the Advertising Identifier, then You agree not to combine, correlate, link or otherwise associate, either directly or indirectly, the prior Advertising Identifier and any derived information with the reset Advertising Identifier."

Note: iAd does not use the AdSupport framework, ASIdentifierManager, or the Advertising Identifier. Therefore they are not required for iAd implementations and should not be included in your app for iAd support. 

If your app is serving ads, please:

- Ensure that you have tested your app on a device, not just the simulator, and that you have removed all previous versions of your app prior to testing

- Provide us the steps to locate ads in your app

If your app does not serve ads, please check your code - including any third-party libraries - to remove any instances of:

class: ASIdentifierManager

selector: advertisingIdentifier

framework: AdSupport.framework

If you are planning to incorporate ads in a future version, please remove the Advertising Identifier from your app until you have included ad functionality.

---------End---------

This one was simple.  When the reviewer reviewed the app, the first thing he/she did was purchase the pro features.  This removed the ads, so the reviewer never would have seen them.  We probably just need to give them instructions to make sure they see the ads.

We are showing Amazon Mobile Ads banner ads and iAd banner ads.  We are also showing Amazon Mobile Ads interstitial ads.  We are not using the ASIdentifierManager at all, but both frameworks use it, so we had to check the box.

I believe that with instructions on how to see the ads, this one will easily be resolved.

I will give an update as soon as we submit and hear back.