How To Deal With Rejection Clause 4.3 – Design

Rejection clause 4.3 — Design

In late 2017 Apple started rejecting apps under the Clause 4.3 Design. You would get a notice like this:

———————-
Guideline 4.3 – Design

We noticed that your app provides the same feature set as other apps submitted to the App Store; it simply varies in content or language, which is considered a form of spam.
———————-

This is a reason for endless controversy. Apple wanted to eliminate hundreds of thousands of apps created with so called app builders, which produce the same code for each app. Thousands of honest developers used those code generating machines to create apps in the same line of business, thus certain app studios specialized for restaurant apps only, for e-commerce apps only, and so on. The apps were technically the same but the content would be totally different and original, catering to the different types of users.

With Guidline 4.3 Apple started throwing out the baby with the water. Thousands of jobs were being destroyed in one sweep, both for apps developers and their customers, who were suddenly left without apps or new versions of the existing apps. The outcry from developers was so loud that one USA Congressmen officialy asked Apple to reconsider, to which Apple had to explain publicly what they really wanted:

each app should be on its own paid account (which would, as one could expect, bring much new revenue for the Apple itself)

and each app should be “original”.

Assuming everybody with different code but identical app footprint were a spammer, they also started suggesting this:

———————-
When creating multiple apps where content is the only varying element, you should offer a single app to deliver differing content to customers. If you would like to offer this content for purchase, it would be appropriate to use the in-app purchase API.

Alternatively, you may consider creating a web app, which looks and behaves similar to a native app when the customer adds it to their Home screen. Refer to the Configuring Web Applications section of the Safari Web Content Guide for more information.
———————-

The suggestion from the second paragraph above, creating a web app instead of a native app, is out of the question. You would have to do everything again: open (and pay for) a new account for Safari development, pay a developer to develop the app from scratch, and so on.

Sometimes Apple will issue this rejection clause even if the app is totally fine but you already have a series of similar apps in your account. If you do not upgrade them often, rejecting a new app is an Apple way of telling you that you need to change things.

So do appeal to Apple’s decision and keep changing the app so that in the end it is accepted. And keep upgrading and changing other apps in your account — that will only bring more downloads to you!

Rewrite Your App in Flutter?

Going through old apps is not easy. Maybe the code used to generate them is too old and will even not compile in the latest Xcode. Meybe the idea behind the app is worn out — there are no more customers for that?

Maybe it is, after all, clear that only one or two apps have bright future ahead of them, while the others can disappear without regrets. If you have an app that used to make money back in the day and could still do so if upgraded to the latest trends — let me know. I shall rewrite it in Flutter and will even give you my own apps server as the backend for the app.

Click here to send me an email. Describe what you have and I’ll get back with candid opinion (no strings attached). 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.