All those years of submitting for AppStore approval

This post was posted on CocoaChina’s homepage: I’ve submitted to the AppStore for review over the years.

// Add by Yunfeng Xiaoluo, 2016.08.04

I’ve been doing iOS development for nearly 5 years, and I’ve been treading on thin ice every time I submit a version, but I’ve still stumbled on some pitfalls. Apple’s official document (AppStore approval terms) is not listed here, because it is too long and tedious, and most of them are not touched by ordinary apps. Today, I mainly want to tell you about my own experience in the past years when SUBMITTING AppStore approval. And some tips on how to avoid it. Big god please ignore, experts please pat.

1. Failure to comply with Apple iOS APP data storage guidelines.

This is especially important if your App has offline data downloads. Offline data usually occupies a large amount of storage space and can be re-downloaded and rebuilt. However, users often hope that the storage space of the system can still exist without problems and will not be automatically cleared by the IOS system. Do not place it in the /Library/Caches directory (which may be cleared by iOS when space is tight). It should only be in the home directory /Documents or home directory /Library/ customizations so that it won’t be automatically cleaned up by iOS. However, this data can be very large. If you put it in the home directory /Documents or home directory /Library/ custom, iCoud will automatically synchronize it, and users will have to consume a lot of traffic to synchronize it, and Apple may reject your application. Therefore, you need to set the “Do Not Backup” attribute for the customized directory in the program.

Points to note about data storage are summarized below:

Critical data

Content: A data file created by a user cannot be automatically recreated after being deleted

Path: Home directory /Documents

Management: the iOS system will not delete the storage space even if it is insufficient, and will also backup to iTunes or iCloud

Cache data

Content: Can be used in offline environment, can be repeatedly downloaded and generated, even if missing in offline, the application itself can run normally

Path: Home directory /Library/Caches

Management: In the case of low storage space, it is emptied and is not automatically backed up to iTunes and iCloud

Temporary data

Content: A file that is generated temporarily to complete an internal operation while the application is running

Path: home directory/TMP

Management: It can be cleared by iOS system at any time and will not be automatically backed up to iTunes and iCloud. Try to clear the application itself when files are no longer in use to avoid wasting space on the user’s device

Offline data

Content: Similar to cached data, it can be re-downloaded and rebuilt, but users often expect it not to be automatically deleted by the system even when storage is tight

Directories: Home directory /Documents or home directory /Library/ custom folder

Management: Similar to critical data, it is not cleared even when storage space is low. Applications should clear files that are no longer in use to avoid wasting space on users’ devices. You need to set “Do not back up to iCoud”; otherwise, the audit fails.

2. No test account is provided

If you need to log in to use some functions of your App, you need to check the demo account and provide the corresponding information when submitting for review, as shown below:

Now many apps in order to be more convenient and fast, to prevent users from forgetting the password, all adopt the way of mobile phone number + verification code, so that there is no way to provide demo account to Apple, unless the account system background is modified to provide support. In this case, there is no need to check the demo account, but please explain to Apple in the remarks that we also want to improve user experience, so we have improved the account system, users can log in with mobile phones, there is no need to register anything, as shown in the picture below. If you don’t say anything, expect to be rejected.

3. No demo video is provided for the app used with related hardware.

This refers to hardware that does not require MFi certification and is connected via BLE (Bluetooth low Power) or WiFi. You can directly provide the demonstration video of related functions in the remarks, as shown below.

The demo video should include the complete operation of the connection process and the demonstration of hardware related functions after the hardware is connected. As you can see from the screenshots of my “Trouser Treasure” demo video, I put it directly on Youku. So is not like the rumor, need to turn over the wall on YouTube, directly put youku tudou or Baidu network disk can. You don’t need to use English, just Use Chinese.

4. App used with related hardware does not provide PPID.(Product Plan ID)

If your App is need to interact through MFi certification of hardware, namely USES the EA framework (ExternalAccessory. Framework), the configuration protocol string (Supported external accessory separate protocols). Then you need to provide the PPID in the remarks message.

Most of the time, our App can adapt to many types of hardware at the same time, and the PPID corresponding to each type of hardware is different. What if, after the AppStore submission is approved, a new model of hardware support is added? Do you need to send a separate version and add the corresponding PPID? The answer is no, because the PPID list information supported by the App is put in the remarks information, adding PPID to the list does not need to modify the binary file information, Apple is also more humane here, can add PPID information without submitting a new version.

5. Used background location service, but did not specify the reason

The Required background modes – app registers for location updates will be configured in the info.plist. But sometime in 2016 Apple suddenly required that if an App wanted to use location, in addition to configuring it in the App, it should also explicitly tell the user what your background location was for, otherwise you’d get an email like this.

1.1 – Apps using background location services must provide a reason that clarifies the purpose of the use, using mechanisms described in the Human Interface Guidelines.

To modify can also simple, the info. According to the requirements of your app in the plist configuration, NSLocationAlwaysUsageDescription or NSLocationWhenInUseUsageDescription fields. The following figure

6. Uploaded screenshots are far from the actual screenshots used by the App

The screen snapshot function provided by AppStore enables users to intuitively understand the functions and interface of the App before downloading it. So Apple also allows developers to tweak screenshots, not necessarily original screenshots. But there is a limit, that is, you can’t go too far, and apple doesn’t quantify the scale. In a big version of the company’s project, a big new function was released. In order to highlight this function, the designer redesigned a set of screenshots of the very Q version of the function demonstration. After uploading the result, I was informed by Apple that the screen snapshot did not meet the function of the App itself.

These are some of the pitfalls I personally stepped on during the AppStore review process. Of course, there are still many pitfalls that my team and I have noticed and tried to avoid. However, I think they also need to be paid attention to.

Found using an undisclosed API

Use ICONS that are close to the system

The interface is too ugly or the interaction is too complex

Unstable and prone to collapse

It’s too similar to other apps on the market

There are detection updates in the App

The name or icon of the third-party operating system is displayed

The testing was not sufficient, and some apps claimed to support operating system versions with compatibility issues

We talked about all the potholes we stepped on, or almost stepped on, just to avoid them as much as possible in future App development. Here I introduce some summary of experience for your reference.

1. Prevention comes first

The functionality planned by the product manager first needs to be determined whether it is technically possible to implement, or implemented without using a non-public API. In many cases, even if you avoid API scanning when submitting for review by using techniques such as dynamic concatenation of function names, you will inevitably be found by Apple in terms of functionality or reported by competitors. Then, I need to have my own judgment on interaction design and UI renderings. The interface should not be too ugly, the interaction should not be too complex, and ICONS that are too similar to the system should not be used.

2. Refer to checklist before issuing the version

For each project, a checklist before release should be accumulated to keep a memory of the pits that have been stepped on before. Some major reasons for recent rejection can also be learned through online information and other means, and the parts that may be related to your APP should be noted, and then checked item by item before release.

3. Pre-submit to AppStore for review

If it has been prevented, checklist has also been consulted before the release. However, sometimes it is unavoidable that there are omissions, especially in versions with many new functions. One of my key recommendations here is pre-submission for AppStore approval. The version of the project has a release cycle. Generally, the App version is basically stable about one week before the release, but some bugs need to be modified and regression testing is required. At this time, you can submit a version to AppStore for review. Anyway, the version number is inexhaustible, as long as it does not occupy the version number set by the product manager. What are the benefits of pre-submission for review?

(1) It can help expose potential problems.

There may be some new features developed in this release, but there may be places where the risks associated with auditing are not considered. If you wait for the end of the project to be officially released before being exposed, it will be too late.

(2) When push comes to shove, test Apple’s boundaries.

Apple audit clause in fact most of the time is not a quantitative standard, such as screen shots with specific when using a far cry from what the screenshot of the App, get a UI designer to screen shot, we sometimes have no way to determine whether really meets apple’s specification, but no relationship, we try to submit to a version to know; Some time ago, Apple required all apps submitted after June 1 to support ipv6-only networks. However, due to historical reasons, a function in the project was used by a third party SDK, and they could not provide a new version supporting IPV6 before our release. Then I read that some people shared that apple is not very strict about this requirement, just need to be able to support IPV6 in iOS9. Of course, as the person in charge of the project, it is definitely not right to cut off this function directly, or to believe what the netizens said and ignore the risk. What to do? Just pre-submit a version and try it out before you decide. The result is that it can indeed pass the review, so the final version did not cut this function, ensuring the integrity of the product online.

4. Urgent review of AppStore

If after previous efforts, you are still rejected, or the release of the App needs to catch up with a certain time operation node, but due to various reasons, the time reserved for App review is too little. This is when you need to use Apple’s expedited review channel.

You search in Baidu iOS urgent review, you will find a lot of claims can help you quickly review the people, 24 hours through the review, the review after the payment, do not pass free. If you don’t know that Apple has an official expedited review feature, you can easily be fooled by these empty-handed people, and the fees start at 5000RMB. Well, I’d really like to say, come with me, I’ll give you 50% off your friendship price.

How does Apple’s expedited review work? On the iTunesconnect page, click “? “in the upper right corner. Icon, select “Contact us” from the pop-up menu,

Then on the Contact Us page, choose App Review – > App Store Review – > Request Expedited Review.

Finally fill out the form with relevant information, the most important of which is why you need an urgent review. It is generally written to catch a major festival operation node, or emergency repair of a serious flash back problem, and then indicate the detailed steps of the phenomenon of flash back, it is ok.

There is no official comment from Apple on whether there is a limit on the number of times expedited reviews can be conducted, and whether the number of times is related to the App or the development account. But certainly, the online rumor that there are only two expedited reviews a year is incorrect. However, in order to make good steel used in the blade, or careful use of this function, in case there is really a need for urgent audit but not response.

Since the first half of this year, app review time has been greatly shortened, and this function is generally no longer needed. The recent versions of Baidu CarLife were approved in 3 days, especially the latest version V2.1.0 that supports EAP connection, which was approved in one night.

Chairman MAO told us, “It is great fun to struggle with heaven! With the struggle, fun! It is great fun to struggle with others!” But as an iOS developer, it’s best to tread carefully when fighting Apple. As a final note, if you know your app has a review risk, but it has been approved by Apple, don’t take any chances and make changes as soon as possible. After all, Apple is a manual reviewer, and just because one version passes may mean the reviewers are in a good mood, but it doesn’t mean the next version will be in a good mood.

Considering the state administration of radio, film and television (sarft) ‘s recent new policy on mobile game censorship, there is no reason to complain about the AppStore’s censorship rules.