This Week's Sponsor:

Kolide

Ensure that if a device isn’t secure it can’t access your apps.  It’s Device Trust for Okta.


10 Years of App Store Controversies

The App Store is a wildly successful product. In 2017 alone it brought Apple somewhere in the range of $11.4 billion, and app developers pocketed $26.5 billion – an increase of 30% over 2016. To kick off 2018, New Year’s Day alone yielded $300 million of App Store purchases. With ever-more Apple devices in the world, the rest of 2018 is sure to end up in the record books.

When the App Store first launched in 2008, it was an unproven concept in the software market. Historically when you wanted to download software for your computer, you would usually visit the developer’s website, which handled both the payment and actual download. While it could be argued that smartphones at that time weren’t proper “computers,” the computer designation undoubtedly fit the iPhone. With its powerful operating system built on Mac OS X, the expectation from many developers was that, eventually at least, the device would gain access to native third-party apps through traditional means. Instead, the iPhone – and subsequently, the iPad – has remained a closed platform. And for 10 years now, the App Store has been that platform’s sole gatekeeper.

Apple’s vision for the App Store has always been driven by privacy and security. Rather than sending users out to a host of unvetted websites to find software that may or may not be what it claims, the App Store was a single unified market for approved, malware-free software to live. As a user, you could download any app in the confidence that it wouldn’t be able to bring harm to your device – and you could do so without providing your credit card details to anyone but Apple.

Apple created and has maintained the safety of its closed platform thanks to its thorough review procedures and guidelines. Every app on the App Store must follow Apple’s rules, which for the most part is widely accepted as a good thing. If an app’s aims are nefarious, it should be rejected by Apple and, hence, not allowed in public view. However, throughout the App Store’s life, there have regularly been controversial app rejections that stirred up the Apple community. Here are a few of those controversies.

Early Days

Even before the App Store existed, developers were chomping at the bit to make software for the iPhone. As such, it should come as no surprise that a flurry of apps hit the App Store in its earliest days. Amid that wave of new apps, on a platform with new, restrictive guidelines, you would expect that app rejections were common in those days. And while there were certainly growing pains for developers in adhering to Apple’s guidelines, for the most part, any negative response to app review procedures was relatively muted – for the most part, developers were simply happy to have the tools to make native iPhone apps.

One of the first high-profile cases of an app review controversy involved a seasoned Mac development team: Rogue Amoeba. Well known for apps like Audio Hijack and Airfoil, Rogue Amoeba published a blog post in November 2009 documenting their troubles getting a bug fix update approved for their sole iPhone app, Airfoil Speakers Touch (now known as Airfoil Satellite). Company founder Paul Kafasis wrote a scathing critique of the App Store, signaling his company’s intent to halt future development efforts:

We wanted to ship a simple bug fix, and it took almost four months of slow replies, delays, and dithering by Apple. All the while, our buggy, and supposedly infringing version, was still available. There’s no other word for that but “broken”.
[…]
Rogue Amoeba no longer has any plans for additional iPhone applications, and updates to our existing iPhone applications will likely be rare. The iPhone platform had great promise, but that promise is not enough, so we’re focusing on the Mac.

Nine years later, despite iOS boasting a much larger market spanning both iPhone and iPad, and big and small changes to App Store review procedures and guidelines, Airfoil remains Rogue Amoeba’s only iOS app.


Airfoil’s use of Apple trademarks had to be removed before approval. Source: Rogue Amoeba.

In 2010, App Store review controversy expanded past the tech community and went mainstream. Mere days after cartoonist Mark Fiore won a Pulitzer Prize for his art, Fiore shared that an app featuring his work had been submitted to the App Store a few months prior, and rejected because:

it contains content that ridicules public figures and is in violation of Section 3.3.14 from the iPhone Developer Program License Agreement which states:

“Applications may be rejected if they contain content or materials of any kind (text, graphics, images, photographs, sounds, etc.) that in Apple’s reasonable judgement may be found objectionable, for example, materials that may be considered obscene, pornographic, or defamatory.”

After Fiore’s story began to spread, Apple quickly reversed course and asked Fiore to resubmit his app, after which it was approved. The situation was resolved quickly due to the massive public spotlight, but the rules themselves, and their entirely subjective application, didn’t immediately change.

Interestingly enough, the current version of Apple’s review guidelines were clearly shaped – in part at least – by the Fiore debacle. Section 1.1.1 outlines objectionable app content being anything deemed “Defamatory, discriminatory, or mean-spirited,” but there’s a catch – the end of that paragraph states: “Professional political satirists and humorists are generally exempt from this requirement.”

2014 and Widgetgate

While every year of the App Store’s life has contained its own set of controversies and developer frustrations, 2014 is undoubtedly the one that stands above the rest.

In the time leading up to WWDC, Apple and developers seemed to have a relationship defined by ambivalence. In part this was due to developers’ continued issues with app review, but it also perhaps stemmed from a growing belief that Apple didn’t understand or care about the realities of indie developers’ lives.

The previous year Apple had introduced iOS 7, which brought a major visual redesign to the platform. Developers had mere months to do the massive work of adapting their apps to fit with the new design, or they would run the risk of having apps that felt outdated overnight. That crazy summer aside, many developers were also growing impatient at the continued lack of power user features that could take their iOS apps to the next level. Apple’s sandbox carried a lot of restrictions – not just for content, but for features – and while hope sprang eternal that that would change in time, the change felt far too slow.

Defying developers’ low expectations, Apple brought a host of iOS improvements to WWDC 2014 that gave cause for excitement again. Share and action extensions, widgets, third-party keyboards, and more were announced as part of iOS 8. Developers breathed a huge sigh of relief – perhaps their requests had been heard, perhaps Apple did care.

Unfortunately, the week wasn’t even out before a new controversy arose.

The bug fix rejection for Editorial was a reminder of past hurts, but it would pale in comparison to the controversy that would come later that year.

As I said, widgets were one of the hallmark features of iOS 8, and developers were excited to add them to their apps.

Apple had initially pitched widgets as a way to quickly view information supplied by parent apps. Developers quickly discovered, however, that they could be used for much more than that.

When iOS 8 launched to the public in September 2014, a new app called Launcher came with it. Launcher was inspired entirely by the new widget feature in iOS – using the app, you could set up custom actions and app shortcuts to be accessed from Launcher’s widget. The “shortcut” functionality mirrored that of existing apps, but the convenience of the widget made Launcher more powerful than the rest. Federico remarked later on about how an existing launcher app had purposely avoided adding a widget:

Launch Center Pro, perhaps the most popular action launcher for iOS, stayed away from trying to add an iOS 8 widget as the developers feared the update could be rejected and, worse, led to outright removal from the App Store.

Launcher was a catalyst of powerful widgets, but unfortunately, it also became the poster-child for Apple’s widget removal requests.

On September 23, 2014, [Launcher’s developer Greg] Gardner was informed that widgets with the type of functionality seen in Launcher would be no longer allowed on the App Store…Three days later, Gardner tried to submit an update with a tweaked widget, but Apple rejected it and removed Launcher from the App Store.

Launcher was not the only app with a widget that drew Apple’s negative attention. Developer James Thomson built a full-fledged calculator into the widget for PCalc that launched alongside iOS 8 and even was featured by the App Store editorial team. However, a month later, Thomson was asked to remove the widget entirely. It was a similar story for Greg Pierce’s Drafts, which didn’t have near as feature-rich a widget – it merely contained buttons to launch different parts of the app – but nevertheless was forced to reverse course in December 2014 and remove its widget.

In all these high-profile cases, an app’s widget was initially approved and made available to users. Only later did Apple backtrack and require that the widgets be removed.

Like many other App Store controversies, the issue ultimately came back to app guidelines that weren’t clear enough, and inconsistent interpretation of those guidelines from one app reviewer to another. If Apple had done a better job up front outlining what was and was not allowed in a widget, Gardner, Thomson, and Pierce wouldn’t have invested any of their time into building the widgets they did. There may have been a little backlash against overly-strict widget rules, but overall iOS 8’s launch would have come and gone free from any widget controversy.

What made matters even worse in this case is that not only had the time and resources been poured into developing these widgets, but the widget rejections had come after the respective updates were already published on the App Store. Users had already begun using and relying on these new iOS 8 features, and while forcing developers to later remove those features may have made Apple look bad to those in the know, all that the average user would know is that one of their apps removed a feature that used to be there.

A couple months after Launcher’s removal from sale, Greg Gardner wrote:

Apple can try to spin this into a positive by claiming that fewer rules allow for more experimentation, but in reality it results in unnecessary developer confusion, fear and angst. The more likely results from such a system are:

  1. A tremendous amount of wasted time for both developers and reviewers when developers create apps that violate unpublished rules.
  2. Developers unsure of whether their app will be rejected end up developing the absolute minimum viable product just in case the time and effort put into the app is wasted if it is rejected.
  3. Developers not developing certain features or certain apps at all for fear of rejection.

It took a six month battle before Launcher finally was allowed back on the App Store. Eventually, Apple simply decided to change its mind on what a widget was allowed to do. Fortunately, PCalc and Drafts didn’t have to wait that long before their widgets were reinstated; PCalc’s re-approval took only a matter of days, while Drafts’ was a couple of weeks.

The scars of 2014’s widget battle are surely still etched into the minds of developers who were building apps at that time. Who can say how many great app ideas have never reached fruition because developers were afraid their apps would get rejected.

Modern App Store

Since 2014, controversies on the App Store have generally been much more muted. Mid-2016 brought a mild tiff involving Spotify’s app update being held up by Apple’s review team, reportedly because the app’s in-app billing option was removed. The issue came and went in due time, garnering plenty of attention, but not as much from the indie developer crowd. Similarly, in early 2017 a New York Times report stated that Apple threatened to remove Uber from the App Store due to the service’s dubious tracking practices. Again though, the matter involved a major company, not indie developers.

In late 2015, Phil Schiller took on primary responsibility for the App Store, and since that time, Apple has seemed generally more developer-friendly. App review times have sped up significantly, subscriptions have opened up to all apps, and there are now much more extensive analytics available to developers. Under the watch of Schiller Apple has offered more tools and features developers have asked for, while also avoiding highly-publicized app rejections in the indie community.

One near-exception to that took place earlier this year, when some apps that used Apple’s emoji artwork started being rejected. Jeremy Burge chronicled the progress of the controversy at Emojipedia, with Apple’s review team demonstrating rampant inconsistency on the issue.


Source: Emojipedia.

Because the main problem was inconsistency, rather than a uniform policy on the matter, the emoji saga tapered off before long. And during WWDC last month, Apple released updated app review guidelines that put emoji-lovers’ fears at ease. Section 4.5.6 of the guidelines reads:

Apps may use Unicode characters that render as Apple emojis in their app and app metadata. Apple emojis may not be used on other platforms or embedded directly in your app binary.

In other words, emoji are officially allowed – provided developers use the proper Unicode characters to add them.


After 10 years, Apple’s general approach to the App Store hasn’t changed. It’s still a walled garden, faithfully guarded by the company’s review team and guidelines. However, what’s allowed on the App Store has certainly grown and shifted as time has gone by. Some of that has been brought about by new technologies Apple introduced, while some of it has been won through hard-earned fights for functionality that benefits users and strengthens the platform we all love.

I’m really pleased to have seen App Store controversies kept to a minimum in recent years. Though I’m not a developer myself, Apple’s review processes and guidelines still matter a great deal to me. Developers make their livelihood on the App Store, and the more trouble they have getting apps approved, the less likely users will be to receive innovative apps. In some cases even, App Store woes can lead to a reduction of great developers working on iOS altogether. That’s a big deal for everyone, not just developers.

Apple appears to have gotten better over time at outlining its policies clearly. They’re certainly nowhere near perfect on this, as this year’s emoji controversy proves, but they’ve improved. Here’s hoping the lessons of the past 10 years will help make the next 10 years quiet on controversy and heavy on app innovation.

OmniFocus 3: Accomplish More Every Day

Unlock More with Club MacStories

Founded in 2015, Club MacStories has delivered exclusive content every week for over six years.

In that time, members have enjoyed nearly 400 weekly and monthly newsletters packed with more of your favorite MacStories writing as well as Club-only podcasts, eBooks, discounts on apps, icons, and services. Join today, and you’ll get everything new that we publish every week, plus access to our entire archive of back issues and downloadable perks.

The Club expanded in 2021 with Club MacStories+ and Club Premier. Club MacStories+ members enjoy even more exclusive stories, a vibrant Discord community, a rotating roster of app discounts, and more. And, with Club Premier, you get everything we offer at every Club level plus an extended, ad-free version of our podcast AppStories that is delivered early each week in high-bitrate audio.

Choose the Club plan that’s right for you:

  • Club MacStories: Weekly and monthly newsletters via email and the web that are brimming with app collections, tips, automation workflows, longform writing, a Club-only podcast, periodic giveaways, and more;
  • Club MacStories+: Everything that Club MacStories offers, plus exclusive content like Federico’s Automation Academy and John’s Macintosh Desktop Experience, a powerful web app for searching and exploring over 6 years of content and creating custom RSS feeds of Club content, an active Discord community, and a rotating collection of discounts, and more;
  • Club Premier: Everything in from our other plans and AppStories+, an extended version of our flagship podcast that’s delivered early, ad-free, and in high-bitrate audio.