Since the App Store launched in 2008, every app and every app update has gone through a process of App Review. Run by a team within Apple, their objective is to keep the App Store free from apps that are malicious, broken, dangerous, offensive or infringe upon any of Apple’s App Store Review Guidelines. For developers who want to have their app on the iOS, Mac, or tvOS App Store, App Review is an unavoidable necessity that they deal with regularly. But in the public, little is heard about App Review, except for a few occasions in which App Review has made a high-profile or controversial app rejection (such as the iOS 8 widgets saga) or when App Review has mistakenly approved an app that should never have been approved (such as the app requiring players to kill Aboriginal Australians).

Earlier this year we set out to get a better understanding of what developers think about App Review. We wanted to hear about their positive and negative experiences with App Review, and find out how App Review could be improved. It is hard to ignore from the results we got, from a survey of 172 developers,¹ that beneath the surface there is a simmering frustration relating to numerous aspects of App Review. There is no question that App Review still mostly works and very few want to get rid of it, but developers are facing a process that can be slow (sometimes excruciatingly so), inconsistent, marred by incompetence, and opaque with poor communication. What fuels the frustration is that after months of hard work developing an app, App Review is the final hurdle that developers must overcome, and yet App Review can often cause big delays or kill an app before it ever even sees the light of day.

Developer frustration at App Review might seem inconsequential, or inside-baseball, but the reality is that it does have wider implications. The app economy has blossomed into a massive industry, with Apple itself boasting that it has paid developers nearly $40 billion since 2008 and is responsible (directly and indirectly) for employing 4 million people in the iOS app economy across the US, Europe and China. As a result, what might have been a small problem with App Review 5 years ago is a much bigger problem today, and will be a much, much bigger problem in another 5 years time.

App Review is not in a critical condition, but there is a very real possibility that today’s problems with App Review are, to some degree, silently stiffling app innovation and harming the quality of apps on the App Store. It would be naïve of Apple to ignore the significant and numerous concerns that developers have about the process.

eBook Version

An eBook version of this story is available to Club MacStories members for free as part of their subscription.

A Club MacStories membership costs $5/month or $50/year and it contains some great perks (including a weekly newsletter with exclusive original content – here’s a sample issue).

You can subscribe here.

(Note: If you only care about the eBook, you can subscribe and immediately turn off auto-renewal in your member profile. I’d love for you to try out Club MacStories for at least a month, though.)

If you’re a Club MacStories member, you will find a .zip download in the Downloads section of your profile, which can be accessed at macstories.memberful.com. The .zip archive contains two EPUB files – one optimized for iBooks (with footnote popovers), the other for most EPUB readers.

If you’re looking for a way to download the file on iOS, check out this post.

The Negatives of App Review

Slow

The loudest complaint amongst the developers we surveyed is that App Review is too slow. We specifically asked developers about the speed of App Review, and the numbers speak for themselves. A whopping 78% of those surveyed rated the speed of App Review in negative terms (bad or terrible), whilst just 10% rated it in positive terms (good or excellent).

Not only did 4 out of 5 developers rank the speed of App Review as bad or terrible, but in the extended answer section of the survey the speed of App Review was repeatedly brought up as a complaint and an area which developers thought Apple must improve upon.

Apple does not publish detailed App Review processing times – the only information they provide is an infrequently updated table which tells developers how many submissions were reviewed (in percentage terms) in the last 5 business days.² But aside from this one page on Apple’s website, developers are given no estimate or indication as to how long App Review might take to approve or reject their app. From our survey, the general consensus amongst developers was that it usually took about a week, but plenty also noted it could be shorter or longer than that.

Fortunately there is also an unofficial source of data relating to the speed of App Review – AppReviewTimes.com by Dave Verwer of iOS Dev Weekly. Operating since 2011, their data is crowd-sourced from developers who post on Twitter how long it took their app to be approved by App Review and append the #iosreviewtime or #macreviewtime hashtag. Any developer can then view the average App Review time for the last 14 days.

Unlike the couple of dozen estimates of App Review times from our survey, the data from AppReviewTimes.com numbered around 7,000 for the iOS App Store and just over 350 for the Mac App Store. That data confirms that the average App Review processing time can be fairly accurately stated as “about one week”.³ The average time does vary month by month, but the average rarely drops below 6 days and is often at 8 or more days.

Developers are frustrated by the slow speed of App Review because it is more than just a minor annoyance – there are real consequences when App Review takes a week to approve apps. The most significant consequence is that apps with software bugs in them take longer to be fixed because not only does the developer have to find the bug, and a solution to resolve the bug, but the developer must then wait for App Review to approve the fix. We heard from a few developers who expressed their frustration and despair at situations where a bug fix (sometimes critical bug fixes) took over a week to be approved. One developer noted that those situations have “been really terrible for customer satisfaction”.

Whilst developers can request an expedited review from App Review, these requests are not always granted. In fact many developers are instinctively cautious (perhaps overly cautious) about requesting an expedited review. They are fearful that it may prevent them from being granted an expedited review in a future (more dire) situation, under the belief that Apple will only grant a developer a certain number of expedited reviews each year.

Beyond delayed bug fixes, a slow App Review process means developers must plan ahead and allocate significant amounts of time for App Review when planning time-sensitive releases – reducing the amount of development time that can occur. One developer noted that they now incorporate a month of slack time into product launches just so they can handle a few App Review rejections.

The slow speed of App Review can also be a drag on innovation, as one developer noted:

Outside of the App Store, most software development has consolidated on agile methodologies and quick iteration, but that is just not possible when there is a minimum of a week for a release to go out.

Finally, the slow speed of App Review makes cross-platform simultaneous releases a bit of a logistical nightmare, as well as making marketing planning more difficult.

Sometimes the slow speed of App Review can be devastating. One developer told me about their app for the new Apple TV which they submitted for review about a week before the Apple TV launched. For an app to be on the App Store when a product launches (whether it is the Apple TV, iOS 9, or the iPhone 6s’ 3D Touch) is incredibly important – not only does Apple’s App Store usually feature great apps that take advantage of the new product, but third-party sites like MacStories also do the same. Unfortunately for this developer, App Review took 14 days to review their Apple TV app, at which point most of the excitement for Apple TV apps had died down and their app was barely mentioned.

Inconsistent

Inconsistency from App Review was another major recurring theme in the survey responses. Numerous developers gave examples where App Review had approved an update containing new features, only to reject a subsequent update for those features which had previously been approved. The most frustrating of those examples were when the update was a bug fix – meaning the developer, trying to quickly resolve an issue for their users, would now have to take more time either modifying their app to comply or appeal the decision (which may not succeed).

One such example was when a small bug fix led to App Review rejecting an app because it required registration. But the app, which had been on the App Store for five years, had always required registration and all of their competitors did the same thing. In the end the app was approved, but it took about a month of appeals and several phone calls to Apple from the developer.

Most concerning was the idea, alluded to in a few of the responses, that some apps were being left to stagnate and die because developers felt that going through App Review again was too risky. These developers felt it was better to just let the app die slowly than risk going through what they feel is an inconsistent App Review, which might reject a long-standing feature – the removal of which would instantly kill the utility of the app.

One developer was working on a emoji-centric keyboard extension for the launch of iOS 8, but kept running into rejections. After a number of these rejections they got the sense that Apple wanted to limit the keyboard extension API to alphanumeric keyboards, not emoji or symbols – so the developer stopped working on the feature. The only problem was that when iOS 8 launched, there were a bunch of emoji keyboard extensions from their competitors. Given that experience, that developer now says that the experience “makes it hard to find the energy to update the app further, or work on any other productivity-oriented app (not for lack of ideas)”.

A few developers provided similar stories of how App Review had rejected their app for some reason which the developer disputed, and after a few messages back and forth it was obvious to the developers that they weren’t making any progress. Rather than continue the argument, these developers decided to reject their own app, and then resubmit the app a few days or weeks later. All of these stories ended in the same way: App Review approved the new build (with no changes) with no questions asked.

Another developer submitted an app which had a Notification Center widget which automatically hid itself – accomplished using public APIs. It was rejected, so the developer appealed the decision but was unsuccessful. After commenting on this rejection on Twitter, the developer understood that some Apple engineers told App Review that this was a valid use case. The developer resubmitted the app, but it was rejected another three times before finally being accepted. Unfortunately the app was then rejected after being approved. This developer also told me that outside of their day job, they no longer build apps for the App Store “because of App Review”.

Poor Communication

A few developers wrote in and described how an app had been stuck in the App Review process for weeks and even months. What frustrated many of these developers was not just the excruciatingly long time in review, but the utter lack of communication from Apple as to why they were in App Review limbo. One developer we heard from said that App Review did not respond to any requests and it was not until they contacted Apple’s Developer Technical Support team did they finally break the silence.

There is a mechanism for developers to send messages to the App Review team, but a common sentiment amongst those who commented on it was that it can often be (or at least appear to be) futile. One developer said App Review simply sends them “canned responses” and another developer even described the feeling of communicating with App Review as “like sending a message in a bottle”.

To the average consumer it may be surprising to learn that App Review frequently calls developers to discuss issues and rejections – which as one developer pointed out, is quite impressive given the massive size of the App Store today. The only problem is, most of these calls are not very useful to developers. That same developer called them “robots” which makes sense when you read this explanation from another developer:

When someone from App Review calls you on the phone to let you know your app has been rejected, the person who calls has little idea what exactly you are doing wrong and no ability to make policy decisions. They generally won’t let you talk to the actual decision-makers, meaning if they don’t understand what you are doing, it is virtually impossible to get on the same page.

App Store Review Guidelines

This is a story about App Review, and as such it also means that the App Store Review Guidelines (Guidelines) must inevitably be discussed. The Guidelines are effectively the laws of the App Store and App Review is both the police and the court system of the App Store.

We asked developers about the “clarity” of the App Store Review Guidelines and this was the most positively ranked aspect of App Review that we asked in our survey, with 30% negatively rating it and 44% positively ranking it. But there were still some developers who criticised the Guidelines as being written in a way which is purposefully vague. A handful of developers expressed frustration at having their app rejected , with App Review simply citing a rule in the Guidelines which is extremely broad. Another developer explained that whilst the Guidelines can be fairly straightforward on their face, “developers are often left guessing about how Apple will enforce them”.

A key criticism from a number of developers was that App Review would use the Guidelines in their most conservative interpretation, allowing App Review to restrict apps and features that they did not like. The consequence of this impression is that some developers say that they avoid developing new apps if something has never been done before, because they view it as incredibly risky. As one developer said, they do not want to “spend months on [a new app], only to have it rejected”.

This developer concern came to fruition in a particularly extraordinary way with the release of iOS 8 and the ability for developers to create widgets for Notification Center. One of the apps which was updated for iOS 8 (and approved by App Review) to take advantage of this widget capability was PCalc, which effectively created a basic calculator that worked in Notification Center. It got a lot of media attention, and in fact Apple featured PCalc in the App Store’s “Great Apps for iOS 8” collection. But at the same time that PCalc was being featured by Apple, App Review had changed their mind and told the developer of PCalc to remove the widget as it breached the App Store Review Guidelines.⁴ The developer of PCalc, James Thomson, went public about Apple’s request to pull the calculator widget, and a public backlash ensued. Fortunately the saga ends on a positive note because Apple ultimately reversed its decision and allowed PCalc and other calculator widgets to remain in the App Store.

But PCalc was not the only app affected by Apple’s shifting of the goal posts relating to Notification Center widgets. Two of the other affected apps were Drafts (seemingly because it used buttons in the widget) and Launcher (because it launched other apps). Like PCalc, Drafts and Launcher both had their widgets approved, then approval revoked, before Apple approved it again (after public backlash against the rejections). It took Drafts’ widget a few weeks to return to the App Store, but in the case of Launcher it took six months before the app could return to the App Store.

The Notification Center widget flip-flopping was, and remains, a real low-point in Apple’s developer relations history. It also highlights the very problem with the App Store Review Guidelines; Apple was happy to twist the vague wording to suit their purposes at the expense of developers. There was no rule against calculator widgets, or buttons in widgets, or widgets that launch other apps.⁵ These were smart developers and they built widgets they believed (rightly) to be within the Guidelines, and in fact App Review initially approved them because they did fall within the Guidelines. When Apple subsequently rejected them they cited vague guidelines and were evasive when the developers tried to understand and resolve the issue.

The Notification Center debacle left scars on developers that go beyond just the developers directly affected. It was a troubling precedent in which Apple callously wielded the Guidelines as a weapon, simply because it disapproved of how an app worked, despite the apps offering genuine functionality to users. There are undoubtedly other developers who have shelved apps or features which pushed the boundaries of iOS because they believe it to be too risky to spend time developing something that might go against Apple’s vision for iOS apps. That should concern Apple.

The App Store Review Guidelines should be like a surgeon’s scalpel, able to carefully and precisely cut out the malicious, deeply offensive, and broken apps. Instead, the Guidelines are more like a bludgeoning club that is barbarically swung, often knocking out the good along with the bad.

A separate frustration borne out of the Guidelines are what are known as “metadata rejections”. This refers to when something in an app’s description or screenshots is in breach of the Guidelines, and because of the way the App Review process works, it means the developer has to resubmit their entire app update and go through the whole App Review process again. Developers find them particularly annoying because it can be trivially easy to accidentally trigger a metadata rejection and App Review can also be notoriously inconsistent about what is permitted and what is not.

Incompetent

One of the most concerning aspects of the survey was that there were quite a few examples of what could only really be described as App Review incompetence.

In one instance a developer ran into an issue where App Review kept rejecting an app because they could not see any of the content in the app. The developer and their beta testers did not have this issue, and eventually the developer came to the conclusion that it must be a problem on App Review’s configuration of their network and iCloud. It took several weeks until the developer reached some Apple employees that accepted the developer’s conclusion and convinced App Review to approve the app.

Another developer once had an update rejected because there was no demo account. Except there was, and the developer had listed the demo account in their app review request. So the developer resubmitted the app without changing anything and the app was approved without issue.

One developer had an app update held “in review” for 32 days. Whenever the developer contacted App Review during this time, they were told nothing was wrong. Eventually the developer contacted someone at Apple they knew and this resulted in a call back from someone in App Review. They asked the developer why they were using HomeKit devices that were unreleased and that the developer should not have access to. Only wrinkle was, the developer was not using any unreleased HomeKit devices.

Another developer had their app repeatedly face metadata rejections because the screenshots of their app featured comic book covers. App Review said the developer did not have the right to use the covers and the developer was forced to use the covers of comic books from the public domain. But as the developer rightly pointed out, there are hundreds of apps which also feature the covers and posters from movies, TV shows, books, and albums.

To some degree it is hard to tell whether developers experience this kind of incompetence regularly. Nonetheless, here is a grab-bag of some other examples, because they really are quite ridiculous:

• A developer had to send App Review a video on how IRC worked after it rejected the developer’s app twice.
• App Review rejected an app for sharing personal infromation because it used Game Center for multiplayer.
• App Review approved Minecraft: Pocket Edition 2
• App Review rejected an App Store screenshot because it contained the iPhone Home button – this is despite the developer using Apple’s own marketing images.
• App Review approved dozens of apps which had been infected with the XcodeGhost malware, potentially affecting tens of millions iOS users.

The Positives of App Review

It must be noted that not every submission focused on the shortcomings of App Review – there were many submissions which spoke highly of App Review in one way or another. The vast majority fit into the following categories:

Helpful

Many of the positive App Review comments related to situations where App Review had been helpful to a developer. A common example of how App Review can be helpful, provided by a number of developers in our survey, was that App Review had discovered a particular bug in their app which the developer and their beta testers had missed. In one instance App Review notified a developer about a graphical bug that only appeared in certain versions of OS X and sent the developer screenshots which documented the bug. Similarly, an update of an app from a different developer was crashing on an older system and App Review sent crash logs to help the developer quickly fix the problem before it was released to customers.

One developer also mentioned that the Developer Relations team at Apple can provide further information and assistance when a feature is rejected, or provide guidance when a developer is concerned that a feature in development may not be approved.

Contacts at Apple

Many developers had great words to say about various contacts they had made within Apple (inside and outside of the App Review team). Developers explained that these contacts were incredibly helpful in situations where the developer had run into an App Review problem and was having no luck in resolving the situation via the normal channels. Although many developers classified the utility of personal contacts at Apple as a positive, others pointed out that if developers had to ask for help from contacts at Apple, it highlighted the very failure of the App Review process.

Expedited Reviews

Apple is not oblivious to the problem of a slow App Review process because they allow developers to request an ‘expedited review’ which effectively permits a particular update to be fast-tracked through App Review. Apple describes it as so:

If you face extenuating circumstances, you can request the review of your app to be expedited. These circumstances include fixing a critical bug in your app on the App Store or releasing your app to coincide with an event you are directly associated with.

Apple will not grant every expedited review request, but developers who have been granted an expedited review for one of their app updates have said the process was fast – usually seeing their app reviewed within 24 hours. Though it is worth noting that expedited reviews simply allow a developer’s app to jump the front of the review queue and skip the “Waiting for Review” phase.⁶

Suggested Solutions to Improve App Review

We also asked developers to make suggestions on how Apple could improve App Review. Although we have not included every suggestion, these were the most frequently mentioned. Because these suggestions are from many different developers, note that some suggestions may be in direct conflict with each other; we are not suggesting that Apple adopt every one of them.

Speed, Speed, Speed

App Review needs to get faster; one week is too long. This was a nearly universal sentiment amongst the developers surveyed. In addition to the obvious “hire more people”, there were a range of other suggestions for how Apple might accomplish faster reviews.

Prioritized Reviews: Some developers felt that those apps which are featured, or are about to be featured should get priority reviews; “left hand, please talk to right hand”.⁷

Minor Releases: Bug fixes and releases with minor tweaks should receive a streamlined review process, or perhaps some kind of review which can be done automatically, flagging potential issues to App Review’s human reviewers. (Counter-point: how do you define what a minor release is?)

Trusted Developers: If an app and/or developer is in good standing and can be trusted, it is felt by some that minor updates and bug fixes should get a “mini” review or no review at all – leaving full reviews for major new features. (Counter-point: how do you define a developer in good standing or what a minor update is?)

Paid Expedited Reviews: It would be controversial, but it was suggested that developers could pay to jump to the front of the line to guarantee an expedited review for critical bugs or to meet a launch deadline. (Counter-point: The danger of course is that this policy would favor the developers with deep pockets and put many independent developers at a disadvantage.)

Roll-Back Updates

If an app has a critical bug the developer has two options; quickly fix the bug and submit the update for review (perhaps requesting an expedited review) or temporarily remove the app from sale and submit a bug fix. But a few developers provided examples where their update had been rejected for one reason or another. This is a nightmare for developers because it means more and more users are exposed to this critical bug, or they are losing even more customers because their app is not available for sale. To reduce the adverse impact, a number of developers suggested the rather obvious solution of allowing a developer to roll-back to a previous version of their app whilst they go through the bug fixing and App Review process.

Partial App Store Release

Bugs are inevitable, but with automatic app updates on iOS and a slow App Review process, a critical bug can quickly wreak (potentially irreversible) damage on an app’s reputation. In addition to the roll-back functionality, it would be useful to allow developers to release an app update to a portion of their user base to ensure everything happens smoothly. Some game developers have done a similar thing when launching new games by limiting their app’s availability to a smaller country such as New Zealand at first – but this “hack” only works for new apps, not updates.

Greater Transparency

What amplifies the problem with App Review’s slowness is that developers have absolutely no idea how long the process is going to take. As one developer quipped, you get more feedback and transparency when you buy a pizza online than you do from App Review. Give developers some estimates so that they can better plan their marketing and development of their next update.

Better Communication

A common suggestion were various ways of improving the communication from App Review. Some wanted App Review to respond quicker, others wanted a dedicated contact so that they could build rapport and work through issues with one person who knows the background of their app. One developer eloquently explained why better communication was important;

“Developers simply want to have a more direct conversation with the person reviewing their app and have the opportunity to discuss or clarify contentious issues in a normal fashion, rather than firing a message into the black box and wait for an App Store Review Guideline to be cited back at you”.

Pre-Approval of Innovative Features

As explained above, some developers are hesitant to pour significant time and resources into innovative features that don’t exist on the App Store yet. Give these developers some certainty by offering a pre-approval process in which the developer can give a detailed explanation of what they want to do, and App Review can provide guidance to the developer as to whether it would be approved and the aspects of their idea that risks falling foul of the Guidelines.

Remove the Threat of Retribution

One of the most absurd lines in the App Store Review Guidelines goes as follows: “If you run to the press and trash us, it never helps”.

A strong argument could be made that without the media highlighting the absurdity of Apple’s position in the Notification Center widgets saga, those widgets would still be banned today. I think we can all agree, whether we use those widgets or not, that iOS would be worse if that was the case.

There’s a reason why we rely on the media to hold governments and corporations to account; it forces them to be better. Accountability is important and it is dissapointing that one of the opening lines of the Guidelines actively discourages, arguably even threatens, developers from holding App Review (and Apple as a whole) to account for its decisions.

Double-Blind Rejections

If an app is rejected, have it automatically re-reviewed by another member of App Review (without informing them that it has been rejected once before). This will help prevent arbitrary rejections and encourage App Review to deeply consider situations in which different App Reviewers come to different conclusions. To prevent waste, obvious breaches of rules such as defamatory or offensive references to religious, cultural or ethnic groups, could be rejected without the need for a second rejection.

Reduce Severity of Metadata Rejections

Rather than require an app go through the whole App Review process again, Apple could allow the app to be approved and instead give developers 24-72 hours to correct any metadata errors. Alternatively, approve the app but require the developer to fix the metadata error (and provide an undertaking to Apple that they have fixed it) before the developer can let the update go live on the App Store. Either option would prevent the wasted time and resources that occurs when a developer has to go through the whole App Review process again.

Clarify the Guidelines

The main complaint about the App Store Review Guidelines is that they can be purposefully vague and have been applied by App Review in ways that are extremely broad. This creates uncertainty for developers, which leads to developers being risk-averse and creating fewer innovative apps. One way to resolve this is to add more detail to the Guidelines and add specificity as to what is not permitted.

Change Attitude

One developer put into words what many others alluded to: App Review seems to have a policy of being conservative at first, and then only over time loosening their restrictions. In that developer’s opinion, it should be the reverse in order to encourage experimentation and innovation. As another developer pointed out, at this point in the life of the App Store it really is quite bizarre when App Review “nitpicks” on an app’s user experience.

Narrow the Scope

Another developer touched upon a similar suggestion – radically reduce the scope of App Review and stop the attempts at being an arbiter of how third-party developers use iOS features in their apps. Keep the focus of App Review on stopping malicious, dangerous and offensive apps and let developers create anything else, even if it may go against Apple’s design philosophy.

Make App Review Optional

I debated whether or not to include this one, because I don’t think it’ll ever happen. It certainly was not a popular opinion amongst the developers surveyed, but it was suggested enough times to merit a brief discussion. Essentially these developers were advocating a system on iOS similar to that which exists on the Mac. They want users to be able to go to the App Store where apps are required to go through App Review, or allow users to download and install apps from outside the App Store (with no App Review). Many of these developers suggested implementing something like the Mac’s Gatekeeper security system as compulsory for all apps (not just those on the App Store) to keep users safe.

Increase Scrutiny

On the flipside, a few developers expressed a desire for App Review to actually increase scrutiny. These developers felt that there should be a higher standard of quality for apps to be approved by App Review.

Shine Some Light on App Review

One developer described App Review as a black box, and a lack of transparency surrounding App Review has clearly been a recurring theme in developer complaints. Apple could pull away the curtain and explain to a member of the press, or at a WWDC session, just how App Review works internally at Apple. Explain the challenges App Review faces, highlight the changes you are making to improve the process for developers and introduce members of the App Review team to the world of developers.

Conclusion

Apple has thrived since the introduction of the iPhone, and a large part of that success can be attributed to the third-party developers who have created a rich ecosystem of apps for the App Store. It should cause concern at Apple that many of those developers have such a low opinion of App Review – a pivotal process that every developer must deal with on a regular basis.

App Review is killing my love of software development. I don’t like punting on good features or app ideas because I’m afraid they might draw a rejection. I dread it every time I hit the submit button. “What kind of silly thing are they going to flag me on this time?” is always in the back my mind. App Review is a process that brings about fear and apprehension in every iOS and Mac developer I know. There’s something seriously wrong with that.

I have little doubt that Apple wants its developers to succeed, but I suspect the huge success of the App Store has overshadowed the real problems with App Review – along with the limited exposure that those inside Apple have of the App Review process. As a result, it is important that Apple takes steps to resolve or alleviate the problems that developers have raised with us. The current situation is resulting in Apple stiffling innovation in small but notable ways, causing undue frustration and lowering the morale of developers.

The situation is far from critical, but it is one that should be addressed in meaningful ways by Apple in the coming months.

Credits

Thank you to every developer who took the time to answer my survey last month. Your feedback was absolutely invaluable, and this story would not exist without it.

The fantastic illustrations that accompany this article are all thanks to the talented Thomas Fink-Jensen, you can follow him on Twitter or visit his website.

Thanks to Dave Verwer of iOS Dev Weekly who kindly provided us with the full archive of raw data from AppReviewTimes.com.

Finally, a big thank you to Federico Viticci, John Voorhees, Myke Hurley, and everyone else who read drafts and helped with the editing of this article.