“We create test prep apps for many certifications and have recently run into the 4.3 Spam rejection problem.”
“We make apps designed to pass vehicle theory tests … Apple is asking us to bundle cars, motorcycles, lorries, etc into one container app…”
“We publish magazines from very different publishers…. Some apps were rejected and the reviewer said it doesn’t follow the 4.2/4.3 guidelines and recommend that we put all apps inside a container…”
“How can I develop a unique feature app for each customers with low budget? Container app in some cases is not an option.”
Wouldn’t it be frustrating when your update got rejected, the reviewer slapped a Guideline 4.3 rejection on you and said that you’re spamming the App Store?
How can you develop one app and sell it to multiple small businesses? A fast-food take-out chain’s app would likely be similar to another, apart from the particular menu on offer, location availability, and branding. Likewise an app for distributing magazines or newspapers won’t be that different from one another, apart from the magazines or newspapers themselves. One church’s mobile app would likely have almost identical use cases to one another — one could argue that the set of use cases may even extend to other organized religions.
Multiple test-prep apps can be built from the same code base. Those apps would be different in their respective coaching content, but same code nonetheless. But they have different audiences — it doesn’t make sense to bundle everything together make one audience pay for test-preps of all the other audiences.
Educational games face a similar problem. Each game is designed for a certain child’s age. It doesn’t make sense to make parents pay for the entire set of games for all available ages when their children are within a certain age range.
But Apple seems to view these kinds of apps as spam since they are identical — a consequence of being developed from an identical code base. But wouldn’t it be great if you can leverage the same code base and deploy multiple apps for these small businesses and organizations? What if you can target multiple segments of the test-prep and educational games market yet not re-create apps for each segment from scratch?
Yes, there are ways accomplish those. Yet you need to have the know-how and tread carefully or face “Guideline 4.3: Spam” rejection.
Surviving Guideline 4.3 Rejection
When you are publishing a series of similar apps for small businesses and your clients want their own branding and presence on the App Store, you would need for each client to have their own Apple Developer Program (ADP) account. This is the white-labeled app business model. Similarly if you are making apps as a companion to a basic hardware that your company provide as OEM to other manufacturers — devices like digital photo frames often fall into this category.
Under no circumstances you should publish white-label apps under your own company’s developer account or risk it being flagged as a spammer. Your clients would need to manage their own legal relationships with Apple and their respective users.
Originally Apple rejected these white-label apps business model. Until a letter from a member of congress made it change its mind. Read How to Publish White-Label Apps in the App Store for more information.
Same Code Base, Multiple Target Markets
When you have multiple apps that targets different markets but developed from the same code base, you would need to migrate all those apps into a single container app. Create a new “super-app” having all the functionalities for all market segments and activate the correct content by having a selection menu during onboarding (first install). This strategy would apply to test-prep apps, city guide apps, age-specific educational games, etc.
I’ve written a guide on how to migrate your existing apps into a new container app. Which includes:
- how to migrate existing users’ licenses,
- how to prevent the app’s download size from bloating having content coming from distinct apps, and
- how to adapt your online marketing strategy for the new container app.
The only way around this is to setup different legal entities for each of the apps’ target market, each with its own ADP account and DUNS number. That is, if you are developing a vehicle theory test preparation app, then you would need to setup a separate company for each vehicle type — e.g. Motorcycle Education Ltd, Sedan Education Ltd, and Lorry Education Ltd. Each company would then publish a Motorcycle License Test Preparation App, a Sedan Driver Test Preparation App, and a Lorry Driver Test Preparation App, respectively. Then your existing app company would white-label to those new vehicle-specific companies and publish each app under their respective ADP accounts differing in content, icon, and name.
Uniqueness is Paramount
Finally if the above doesn’t apply and app reviewer doesn’t cite a specific reason for the Guideline 4.3 rejection, maybe your app is not unique enough. Keep in mind that reviewers has about five minutes to pass/reject an app and if the reviewer seen something similar before then he/she would be keen to mark your app as spam. Moreover, apps not having an English localization tend to be more prone to this.
I’ve written a guide to prevent your app from being seen as spam. This includes verifying the design among your own apps and comparing it with other competing apps.
Quoting the App Review Guidelines:
… avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, fortune telling, dating, and Kama Sutra apps, etc…
If you’ve recently had a Guideline 4.3 Spam rejection, then these are the three solutions that you can approach depending on your particular situation:
When you are planning to make a series of similar apps, remember that Apple dislikes the idea. Consider choosing either the Container App or the White-Label App routes, depending on the app’s business model.