10 ways to get your app kicked off the App Store

Few businesses in history have erupted like those on mobile.

TikTok is an obvious example. Pokemon Go was the poster child for overnight success a couple of years ago and while we don’t hear about it anymore, it is still raking in dumpster-loads of cash: $193 million in the last three months, according to Apptopia.

So it’s critical to be on Google Play and the iOS App Store. But, as developers know, it’s harder to get on the App Store, and there are more guardrails about what you can and cannot do in your iOS app.

So I thought I’d put together an iOS 14-flavored list of the ways to get kicked off the App Store. Some of these have been around for a while. Others are brand-new with iOS 14.

1. Tell people to go buy IAPs on your website

Option number one to get kicked off the App Store (and Google Play, by the way) is to offer purchases that will be valuable in your app, but ask people to buy them on your website so you can avoid the 30% platform fee.

Obviously, this is what got Epic’s Fortnite booted. And it’s now the focus on a major lawsuit, as well as antitrust attention.

This is a bit murky, however.

Guideline 3.1.3 allows some types of apps to access purchases made outside of the app, like reader apps, multiplatform services, enterprise services, or person-to-person sales. But you still can’t explicitly tell people to go elsewhere to buy things in your app. Nor can you use “points of contact obtained from account registration within the app (like email or text) to encourage users to use a purchasing method other than in-app purchase.”

2. Hide functionality in your app to reveal later with a cloud-based change

Hiding functionality in your app is also a good way to get kicked off the App Store. There’s an obvious reason for it — apps with hidden code could execute serious privacy and security breaches on unsuspecting users — but it’s also tough on good developers, who might want to build functionality that they will reveal later.

Updated rule 2.3.1 says “Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review.”

The flip side is: don’t say your app does something it does not actually do. Guideline 2.3.1 states that ”you should not market your app on the App Store or offline as including content or services that it does not actually offer … egregious or repeated behavior is grounds for removal from the Developer Program.”

One target of that guideline: VPN apps that claim to make your browsing experience private and safe, but actually collect, store, and sell data about where you’re going. This has happened multiple times, including recently.

3. Include ads in push notifications and widgets

Marketers advertise, right? Sure, but good marketers know when and where to advertise, and how to do it ethically. Apple has decided that ads should not be presented in notifications and other areas of iOS mobile operating system.

But there is a loophole.

Guideline 3.2.2 says that “monetizing built-in capabilities provided by the hardware or operating system, such as Push Notifications,” is unacceptable. The loophole is in another guideline, 4.5.4, where Apple says that “push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them.”

In other words: get your permissions squared away.

4. Include third-party analytics in your kids-focused app

Most developers know this by now, but if you’re publishing apps just for kids, third-party analytics solutions are problematic.

Guideline 1.3 says “apps in the Kids Category should not include third-party analytics or third-party advertising.”

Again, there’s a loophole, however.

“In limited cases, third-party analytics may be permitted provided that the services do not collect or transmit the IDFA or any identifiable information about children (such as name, date of birth, email address), their location, or their devices,” Apple says. “This includes any device, network, or other information that could be used directly or combined with other information to identify users and their devices.”

If you’re including third-party analytics, be prepared to show Apple exactly how they’re working, what they’re collecting, how you’re ensuring they’re not collecting any banned data, and how you’ll make sure that situation persists over time.

5. Collect unauthorized data from your users

There’s a clear directionality to Apple’s evolving guidelines over the past years: more privacy, less risk. At the heart of that is data minimization in guideline 5.1.1(iii): “Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task.”

This is a very sensitive area and it’s not just about what you collect.

It’s also about what any third-party software in your app might be collecting. For instance, a fraudulent ad network SDK could be collecting data to steal credit for other ad networks’ efforts, as we saw in the recent fraud incident (which Singular protects clients from, by the way). And you don’t even necessarily have to add the ad network’s SDK to your app manually: it could be embedded in your mediation platform.

So it might not even be your fault, which is why you need to vet your partners very, very carefully.

And, of course, you need to not be a bad guy yourself. As Apple says, “developers that use their apps to surreptitiously discover passwords or other private data will be removed from the Developer Program.”

6. Make people enable tracking to unlock features

Some publishers floated this idea in the early days of iOS 14’s release: can we ask people to enable IDFA-based tracking in exchange for access to features and functionality, or in-app rewards?

Apple’s response: “Nuh-uh.”

See the highlighted part of App Store guideline 3.2.2(vi):

“Apps should not require users to rate the app, review the app, watch videos, download other apps, tap on advertisements, enable tracking, or take other similar actions in order to access functionality, content, use the app, or receive monetary or other compensation, including but not limited to gift cards and codes.”

7. Use fingerprinting in place of IDFA for tracking purposes

The other fond dream of mobile marketers — or ecosystem players with extensive device graphs — was that if IDFA was out, fingerprinting was in.

Fingerprinting is identifying a device by its characteristics: location, device data, language, and more. This has been easier on desktop web and Android than on iOS, thanks to a more limited array of data available from iPhones, and while it decays rapidly over time, can still approach from 80% to high 90% accuracy.

However, Apple considers it simply another form of tracking (probably because it is) and says that if you have not obtained tracking consent, you cannot use it.

8. Offer a controversial and/or potentially dangerous product

You might think this goes without saying, but not always. Clearly some dangerous content is not going to fly on the App Store, but there are things that are OK one year, and not OK the next.

Vaping is a good example.

As the medical dangers of vaping grew more and more obvious, Apple made a decision to remove all vaping apps from the App Store.

“Recently, experts ranging from the CDC to the American Heart Association have attributed a variety of lung injuries and fatalities to e-cigarette and vaping products, going so far as to call the spread of these devices a public health crisis and a youth epidemic,” Apple told Axios. “We agree, and we’ve updated our App Store Review Guidelines to reflect that apps encouraging or facilitating the use of these products are not permitted. As of today, these apps are no longer available to download.”

That’s guideline 1.4.3, and it covers “tobacco and vape products, illegal drugs, or excessive amounts of alcohol.”

There’s not much you can do as a developer here, except try to avoid categories that could have negative legal, ethical, or medical consequences.

9. Poke the bear (and offer insane pricing)

As much as you’re an independent company or publisher, you’re accessing the market via another company that controls your ability to do so.

So bad-mouthing Apple is probably not a great strategy for long-term financial stability, as the developer of the Zits & Giggles app discovered recently. Apple probably won’t kick a developer out for simply badmouthing them, but it won’t help … and when paired with an odd and excessively expensive pricing strategy — up to $400 for a simple casual game — you should not be shocked to get the boot.

Of course that’s not the first time we’ve seen insane app pricing: you might remember the I Am Rich app from 2008, the dawn of the App Store.

Developer Armin Heinrich decided to play around with app pricing and eventually hit on the idea of offering a $999 app that did nothing but display a diamond. Apple, in turn, decided that this was ridiculous and banned the app for not providing any utility.

(Interestingly, the app is back on the App Store now with some calculation capabilities for just $8.99. Given that pricing, you might argue that perhaps the app name is now misleading.)

10. Use a private API

There are few things Apple dislikes more than a developer using a private API, which is why this app that enabled cloud gaming in Google Stadia got tossed out of the App Store for a few weeks.

App Store guideline 2.5.1 is pretty clear: “Apps may only use public APIs and must run on the currently shipping OS.”

You could potentially run afoul of this guideline unintentionally, because APIs do get deprecated. So Apple says “keep your apps up-to-date and make sure you phase out any deprecated features, frameworks, or technologies that will no longer be supported in future versions of an OS.”