Summary of experience after App Store review was rejected 5 times!

Including the Beta version review, our app has been submitted to App five times and has been rejected five times. Here we summarize the various reasons for being accused.

2.2 – Apps that exhibit bugs will be rejected

The program has a bug, which should be the most obvious reason for rejection. But who would submit a version with obvious bugs?

We have a "Log in with WeChat" button, and the reviewer told us that it is "unresponsive when tapped". The reason is that we did not check whether the user has WeChat installed, resulting in the button being unresponsive on devices without WeChat installed.

10.6 – Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected

This statement is actually very vague. Your program was rejected because it was too bad. Fortunately, the reviewers will explain exactly where the "difference" is every time, and attach a "Next Steps" to tell you how to solve it. (However, the Beta version reviewers will not do this. It feels like these are two different departments with slightly different review standards. The review for the official version will be stricter, which will be explained in detail below.)

Apps should be able to run on launch, without requiring additional applications to be installed.

This sentence is very important. We were rejected twice for this reason. Our application requires login. At the beginning, we only provided a third-party WeChat login. After the first submission, we "thoughtfully" added a judgment. When the user does not have WeChat installed and clicks WeChat login, he will receive a pop-up window reminding you that it is not installed. Not allowed.

When we submitted the application for the last time, we added QQ as a login method. However, the mobile SDK provided by QQ had the same problem as WeChat. We could not log in without installing the application, and even worse, we could not log in without installing the latest version. Without a doubt, we were rejected again. This time, the reviewer was very considerate and used the word "still": We still find that your app requires the installation of another app before it can be used. So we were very smart and adopted the QQweb login method to bypass the problem of having to install mobile QQ. It took a lot of effort, but in fact it was not very meaningful. There are only a handful of users in China who do not install mobile QQ, and people who do not use QQ are basically not potential users of our application.

This finally allowed us to pass the Beta version review, but when we officially submitted it, it was still rejected.

Apps should be able to run on launch, without requiring additional applications to be installed.

This sentence is very important, so I have to say it twice. When WeChat was not installed, we gave a prompt and it was not allowed. In the view of the reviewers, your practice is "required to install WeChat".

A more convenient approach would be, "If QQ is not installed, the QQ login button will not be displayed; if WeChat is not installed, the WeChat login button will not be displayed." If you really want to use a third-party login, please use Weibo. Their SDK is very considerate and allows you to use web login when Weibo is not installed. It is best if you provide a test account for logging in. It is also worth noting that in iOS, necessary operations should be completed within the app and should not pop up outside the app. We used a sharing function of QQ. When QQ is not installed, the QQ SDK will pop up in Safari to ask users to log in. Because of this, we were rejected again.

17.2 – Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected

The auditors told us that we used the login authorizations for QQ, WeChat, and Weibo, but “does not include account-based features offered by that site” and did not use the corresponding functions provided by their website.

To solve this problem, one must either add “account-based features of that social network” or use one’s own account system. However, information on the Internet tells us that our own account system must have a complete set of functions, such as password retrieval, otherwise it will involve collecting user information.

✦Guest Mode

We have debated for a long time whether or not to adopt the visitor mode. Theoretically, if you have your own complete user system that can be registered, then there is really no need for a visitor system. There are many such applications, such as WeChat, QQ, and Nike Training. But most applications have them. This question is considered more from the perspective of user experience: whether users must log in to use them.

✦What if only third-party login is available?

This is a tricky question. According to 17.2, there must be "account-based features of that social network." Our understanding on this issue is that if your application is based on personal accounts and all functionalities are centered around the user system, then providing only a third-party login is far from enough. You must have your own user system. On the contrary, if login is a bonus for your application, such as "The Most Beautiful Application" or "ZAKER" (they have just closed registration for their own accounts), then it is OK to only use third-party login.

The reviewer said that once our app is opened and the data is downloaded, more than 3 megabytes of data are generated. By default, these data are stored in /Documents, and the data in this directory will be synchronized to iCloud by default. However, only data generated by the user himself can be synchronized. In short, we saved it in the wrong place. What we saved is actually cache files, which should not be synchronized. We can just add the "do not back up" attribute. Of course, to be on the safe side, cache files should not be stored in /Documents.

<Application_Home>/Documents can only store user-generated files.

If you want to use the application offline, your cache files should be in <Application_Home>/Library/Caches.

Things placed in <Application_Home>/tmp should be deleted after use.

You can also set the data that users put in documents not to be synchronized to iCloud to save the user's iCloud space. (After all, you paid for it)

The above four are the four rules mentioned in iOS Data Storage Guidelines.

Another thing worth noting is the exposure of application data in iTunes. Users can directly access the data in Documents through iTunes. So if you don't want users to get the data, you shouldn't put it here.

ASO optimization service click link: ASO optimization service introduction

IOS accelerated review click link: //www.opp2.com/8854.html

APP Top Promotion (www.opp2.com) is the top mobile APP promotion platform in China. Welcome to follow our official WeChat public account: appganhuo

[Scan the top APP promotion WeChat QR code to get more dry goods and explosive materials]

This article is compiled and published by (APP Top Promotion). Reprinting this article must be approved by Top Promotion , and please attach the link to this article!