Once upon a time, in a basement far, far away, there was an iOS developer. She had been working hard for hundreds of nights and days, working on her new and amazing iOS app. Finally it is ready for the world to see. She submitted it to the App Store for review, but alas she was met with dismay…
Guideline 4.2 – Design – Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value, it may not be accepted.
App Review rejected her app with a terse excerpt from the App Store Review Guidelines. She didn’t know what to do or what change in the app to get it pass the review. She pleaded those gatekeepers for more information, only to receive robotic regurgitations of those same words.
She grew desperate. Her dreams shattered. Her hopes squandered. She wished upon a star, begging to the spirit of Ada Lovelace, the guardian angel for all developers, yearning for a way out, “If only I know what can I change in the app to get it pass review… If I only know what should I do….”
Does this sounds familiar?
This can also happen to you. All those days and nights spent toiling on your app, only to have it bounced at the gates of the App Store.
Fear not my fellow developers. When you’re done with this article, you’ll know how to get your app to pass the App Review. Keep in mind the advices herein while you’re designing a new app, submitting your first app, or even work at an update to an existing app — if you want to be sure to get it pass App Review purgatory.
Common Causes of “Guideline 4.2” Rejection
Some of the more common causes of App Store rejection that ends up rationalized as “Guideline 4.2: Design – Minimum Functionality” are:
- The reviewers did not understand the app.
- The sum of functionalities can be done not as an app.
- The app is merely a promotional material (and nothing else).
Let’s go through these one by one.
The reviewers did not understand the app
App Store reviewers are people too. Sure there are a number of static analysis suites that gets run on your application bundle on upload. But afterwards, a human reviewer will run your app and go through it. A typical manual review will be about five minutes. These reviewers have a lot of apps to go skim through and probably each employee has a minimum target in order to keep their jobs.
If you can’t get app review to understand your app, they are known to reject it via the Guideline 4.2 clause. On the flip side, this may be a good thing because users in the wild often won’t give you a reason. If you can’t get app reviewers to understand your app — or at least to get a feel on what it does within five minutes or less — how can you attract users from the general public? Remember that these reviewers themselves have been vetted in the hiring process, hence have a minimum level of intelligence. That won’t be the case with random users of the App Store.
In any case, if your app is only meant for a very specific audience, the App Store may not be a good channel to distribute your app. Have a look at the custom app distribution method and see if that’s a good fit. Apps distributed through this channel won’t need to go through the standard app review process.
The sum of functionalities can be done not as an app.
The App Store is already crowded. Every new app published raises the bar of minimum functionality by a tiny bit. This is to ensure that a certain level of quality present in App Store apps.
If your app is primarily reference materials and has little or no interactive features, then it would be vulnerable to “app is a book” rejection. Consider delivering your content as an e-book instead. This would also include game guides, repair manuals, and the like. Remember that e-books nowadays can also include multimedia content.
If your reviewer feel that your app can be done through the web browser, he/she would tend to reject it. Apple’s stand on the App Store is generally, “If it can be done on the web, it should stay on the web (and out of the Store).” Consequentially, the Safari team keeps building features to bring more capabilities to web apps that were previously only available to native apps. Of course web standards, being committee-driven, tend to trail native platforms’ capabilities. That’s why apps that wants to be in the store would need to prove that it’s really native-worthy.
Your app is just a promotional material
The IKEA Catalog app did little else than providing listings of its products. Sure it had a functionality that placed products in the user’s environment via augmented reality. You might thought to ship a similar app showing your products or services, hopefully getting some visibility by being present in the App Store.
That idea is highly vulnerable to Guideline 4.2 rejection. IKEA may had an app in the store which was little more than marketing materials, but IKEA is a billion-dollar company, Large corporations aren’t subjected to the same App Store review rules as small businesses. Life is unfair, deal with it.
But, you might thought, the exact wording of the guideline says,
4.2.2 Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.
That allows catalog apps, doesn’t it?
Yes, technically it does. But Apple called this document guidelines and not agreement — thus can bend it as appropriate. Unless you have the budget to challenge the reviewers in court. If you do, then probably you have the backing of a million-dollar company, at the very least.
In short, the App Store won’t be a good place to promote your products or services. It actively rejects apps that’s trying to do that and it’s already overly crowded anyway. That said, providing access to your products or services through an app is an entirely different conversation.
How to Avoid App Store Rejection
If you’re still in the idea phase of your app when you’re reading this, then congratulations!. There are plenty you can do to ensure success as you’re early enough in the product lifecycle to allow for major changes.
Before you begin writing the first line of code for the app, ask yourself, your team, and an independent third party, “Is an iOS app appropriate to solve the user’s problem?” Can it be delivered via the web? Would an e-book cure the pain? What about other means to deliver the solution?
Better through the web
If your app isn’t leveraging native platform features, consider doing it as a progressive web application instead of a native iOS app. Hence you can bypass the app review process altogether and gain multi-platform support at the same time.
Besides, some use cases are better to be “web-first” and maybe have an app to supplement the web. This includes most remote-collaboration and social media use case stereotypes. Catalogs and galleries are also better to be web first — having a permanent link for every item would facilitate site visitors to share your offerings to their friends and colleagues, which may not be an iOS user.
Keep these in mind when you are scoping your app, before you even create an Xcode project for it. Remember to step back, design all of your app’s functionalities, all of its flows, all of the features for the first version and a roadmap for the second version. Then take a look at the current Web Browser APIs. Perform a technology mapping exercise and see if your app is really doable through the browser.
Because if your app doesn’t leverage iOS’ native capabilities, App Review would likely reject it. If your app is merely web-app repackaged into a Cordova container, without any plug-ins, that’s a good sign that it’s not going to pass the review. This is not saying that Cordova isn’t allowed in the App Store, but to remind that if it can be done as a web app, it should stay on the web.
If your app is mostly an info-product, consider delivering it as an e-book. Nowadays e-books are not limited to text and graphics. The iBooks format supports audio, video, and even interactive elements through HTML5 widgets. Moreover if you publish these through Apple Books, you also gain auto-update functionalities, much like an app.
The Apple Books platform is quite powerful and often overlooked. With the iBooks format, readable through iOS 6 or later and macOS 10.9 or later, an e-book can have multimedia and interactive content. Have a look at the list of built-in widgets and some 3rd party widgets that an iBook can provide. If there’s a functionality that you need that isn’t there, chances are you can add it yourself (or get a pre-made one) since the iBooks supports almost everything that a web browser can do.
Even the cross-platform ePub 3 file format supports embedding video content. In turn the format has been supported by Apple devices since 2012. Being an open standard, there are ePub readers for Android and Windows as well. Thus you can deliver your collection of instructional videos as an ePub file, which can be viewed offline (and consumed in an airplane).
That said, there are other platforms (outside of Apple’s) that are designed to specifically deliver multi-media books, among those are:
Have a look at those channels and see if they are more appropriate for delivering your content.
How to Get Through App Store Rejection
When you’re already done with your development work yet rejected by the App Store, some small changes can make it pass. As long as the app is not fundamentally against the app review guidelines.
Here are some points to ponder when your app got rejected due to Guideline 4.2:
- Do you have an intro screen showcasing an overview of your app’s full capabilities?
- Do you have some pre-populated sample data which demonstrates your app’s value proposition?
- Does your app integrates with iOS’ native features in ways that can’t be done by a web app? (Likewise does App Review know how to use this part of the app?)
- Does your app have an English user interface? (In addition to your target audience’s preferred language?)
Add Intro Screens
Keep in mind that an app reviewer only has about 5–10 minutes to skim through your app and make up his/her mind. Thus you need to build your app in with this very important albeit seldom-executed work-flow in mind.
Having a first-run “welcome” screen highlighting an app’s features would help the app reviewer to quickly glance over what your app can do. Likewise this should also help first-time users. As what Steve Krug, the UX expert, said, “don’t make me think” — make every attempt to reduce the app reviewer’s mental burden as much as possible. Your users would thank you for it.
Nonetheless intro screens tend to get in the way of the user’s task in mind. Thus ensure that these are always easily dismissible. Don’t force users to go through pages upon pages of introductory materials.
You can also take a page from Apple’s book (pun intended). Have a short-intro showing three features of the app that are new and should be most interesting to the user. Only show this intro once for every major release of the app, typically releases that introduces these new features. Remember to make it a dismissible dialog so that it won’t block real users’ workflow.
Besides intro screens, you can also embed these “how-to” snippets in other parts of the app. Examples include:
- The background of “empty state” screen (notably in split-view iPad apps).
- Info-cards (or cell) in news, feed, or other apps featuring a list of contents.
- One-liner tips in dialogs, coupled with an information disclosure button that provides further details on the tip.
The encompassing theme is discoverability and learnability. Make sure that the reviewer can discover your app’s differentiating features and your users would too.
Only having five minutes to review your app implies that App Review won’t take the time to perform data entry. Similarly, real users would like to know what’s to gain before investing time and effort to enter data. (Probably only enterprise users would tolerate apps requiring significant data entry before doing anything useful – because their boss tells them to use it and their jobs depends on it).
If on first run the app just shows a blank screen and ask the user to input a lot of data, that’s simply asking to get a Guideline 4.2 rejection. Normal new users unfamiliar with your app would also get turned off by this kind of thing. They would either put a “useless, 1-star” review in the App Store (if it’s a free app) or contact Apple to cancel the purchase of your app and refund their money.
For example, a health-reporting app requiring a month’s worth of intensive use before showing its value would simply be a no-go as far as App Review is concerned. Reviewers won’t be patient enough go through the regimen needed by the app to generate its reports. Therefore this kind of apps would be better when included with a sample user profile already having all the data and show a complete example of those reports. Tell the user, “Hey, if you do all of these things and provide all of these data, then the app would crunch your numbers and provide a report like this but tailored to you.”
By being uni-platform, I don’t mean to only exclusively develop on iOS and never bring the app to other platforms – nor to take down already-existing apps from other platforms’ respective app catalogs. Instead, your app’s workflows need to take advantage of iOS’ unique features, interoperate well with other apps in users’ devices, and be a good-standing citizen of the platform. Not just bolt-on features just for the sake of integrating it. Not just just be a “lowest-common denominator” of all the platforms that you support — that’s what web-apps are for.
Customizing the app for each platform often means having dedicated teams working for each. These are the people that should be the “platform experts” who knows which platform-specific features are appropriate for the app and what integration points appropriate for interoperability with the platform or other applications.
For example, an iOS app would probably do better when it integrates these platform-specific features where they make sense:
- Voice commands or SiriKit.
- Machine learning through Core ML.
- PIM integration — calendar, contacts, to-do, photos, health, music, etc.
- Deep linking.
- Sharing to other apps (or from other apps).
- Physics-based user interface effects through UIKit dynamics.
- App extensions – enrich functionalities of other apps on the user’s device.
- Push notifications (web push only available to Safari on the Mac but not iOS as of iOS 13)
In short Apple would love it if you make iOS shine through your app, in ways that it can’t be done in other platforms. That would be a very strong argument to be in the App Store.
As a whole, the App Review team claims to understand 81 different languages. But that doesn’t encompass all of the world’s languages. Even if your app’s language is among those that the team understand, chances are those having working proficiency of the language is already overloaded with other uni-language apps pending for review.
Hence it’s very desirable to always have U.S English as one of the user interface languages of your app. The same goes for its App Store description Even if you only release to one country’s App Store or only target that language’s speakers. Remember that these app review teams are Apple employees sitting in Cupertino, not outsourced temp workers from the app’s target country.
You may argue that it’s not worth investing the effort in providing English translation of the app, since the target market doesn’t speak the language. Nevertheless, app review is also a use case of your app — a very important use case that can prevent any other use case from being executed, if your app get rejected.
To put things into perspective, I’m not a monolingual American. English is not my native language and the closest I’ve been in a United States territory was in one of its embassies. Thus please spare me the language bias lecture.
If you’ve just submitted your app and received a rejection, pay attention to the specific guidelines that were highlighted in the rejection message. See if you can introduce quick fixes to address these rejection reason. In my experience, many app store rejections can be solved by a few changes to satisfy the review comments.
If you’re in the middle of the development cycle, take a step back to catalog your apps’ features and workflows. See how much of it can be done as a web application. Try to incorporate native platform features that are not available to a web application.
However when you are still conceptualizing the app, it would be the ideal time to make large changes to ensure its success. Defer any technology decisions until you have the full picture of the solution. Then perform a technology mapping exercise to decide which technology, platform, channel, or a combination thereof most appropriate to deliver your solution effectively.
If you’ve read all the review guidelines, are sure that your app is not against all of these guidelines, and went through all of the tips in this article, chances are it’s a mistake of the reviewer. You could encounter an inexperienced reviewer or maybe the important features in your app were overlooked. In that case try submitting an appeal. Your app will get a “special look” from the more senior members of the review team. If if it’s indeed a mistake of the original reviewer, the review board should approve your app for release.
That said, Apple do have a history of sherlocking — taking ideas from 3rd party developers and building competing functionalities into the platform. This sometimes makes it harder for those first-to-market developers to compete. A recent example case of anti-competitive sherlocking is 3rd party parental control apps for iOS versus Screen Time. Unless you’re being sherlocked — that is a platform functionality overlaps with your app, either existing or upcoming functionality – addressing the points described herein should help you favorably.
However if you’re sure you’re being sherlocked, then these can be your options.
- Submit an appeal to the review board. This is Apple’s recommended method.
- Take it to social media. This is un-recommended by Apple as per guidelines and it’s likely to burn bridges. However the strategy had been effective in some cases. On the other hand it may also backfire.
- Take it to the courts. Probably has a better chance of success if you are based in the European Union, as its courts tend to have an anti-monopoly bias and was successful in getting Microsoft to promote other web browsers apart from its own.
Some sherlocked apps can still be offered in the App Store. Moreover some thrive by offering more functionalities than the built-in ones, examples include Duet Display and Luna.
Thats all for now. I wish you success!