如何提升iOS审核的通过率

原文来至：http://wwwcnblogscom/haohao-developer/p/5626821html
负责 iOS 应用开发的同学们，想必已被 APP Store 的审核机制折磨心累不止。新的一年，又一轮审核即将来袭，你们做好准备了么？
为了帮助各位 iOS 应用开发的同学免受折磨，腾讯 Bugly 特邀互娱 iOS 预审组的同学通过大量的数据分析，对苹果的审核机制进行了一番总结，连夜赶稿写出提升 iOS 审核的通关秘籍（因为内容较多，因此分为上下两篇），来与大家分享。
经过互娱 iOS 预审组近一年的数据监控，分析过往提审被拒的案例，我们对 iOS 的审核进行了缜密分析，统计出最常见的被拒原因：
通过以上案例，并结合《苹果应用商店审核指南》，大体可以将审核工作分为三块：客户端资源检查、应用内容检查、提审资源检查，我们将通过这三步来为您揭秘iOS审核的真相。
第一步：客户端检查篇
客户端检查的主要目的是通过客户端配置检查来保证客户端符合苹果的开发者规范以及其他更新的要求，包括存储系统、配置文件、网络连接（***）、icon检查、私有API检查，提审前的审核会覆盖这几个部分的各个测试点。
1存储系统检查
苹果官方对用户数据存储有严格的规范，因此如果要通过审核，首先要了解一下苹果官方数据存储指引的相关内容：
被拒条款：223
Apps must follow the iOS Data Storage Guidelines or they will be rejected( 应用启用iCloud存储功能后，必须遵守iOS数据存储指南，否则将被拒。)
被拒案例
被拒原因描述如下：
We found that your app does not follow the iOS Data Storage Guidelines, which is required per theApp Store Review Guidelines
In particular, we found that on launch and/or content download, your app stores 56 MB To check how much data your app is storing:
Install and launch your app
Go to Settings > iCloud > Storage & Backup > Manage Storage
If necessary, tap “Show all apps”
Check your app’s storage
The iOS Data Storage Guidelines indicate that only content that the user creates using your app, eg, documents, new files, edits, etc, should be backed up by iCloud
Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app
Data that can be recreated but must persist for proper functioning of your app - or because customers expect it to be available for offline use - should be marked with the “do not back up” attribute For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute
简评:
应用在启动时就在Documents下产生了56 M的数据，说明不是用户自行创建并用于备份的，通过修改应用，在document目录加一个不备份的属性(NSURLIsExcludedFromBackupKey)后审核通过。再来总结一下iOS5以后的存储规范：
ü 只有那些用户生成的文档和其他数据或者是那些不能被你的应用所重建的数据应当保存在/Documents 目录内。这些数据文件将会自动的通过iCloud备份。
ü 那些可以重新下载或者重新创建的数据应当保存在/Library/Caches 目录内。你可以把数据库缓存文件或者可下载的内容如杂志、报纸、地图应用的数据等放入缓存目录里（Caches directory）
ü 临时需要的数据应该保存在/tmp 目录内。尽管这些文件不会备份到iCloud里，但记住不再需要它们时立即删除掉这些文件，这样它们就不会继续浪费用户设备的储存空间了。
ü 使用“do not back up”属性指定不需要iCloud备份的文件（比如需要离线环境使用的文件；该属性能在任何目录下生效）。由于这些文件占用设备空间，所以应用需要有一套定期监控与清理这些文件的机制。
应对措施
本例中该应用未启用iCloud备份，如果启用了iCloud备份，则可以通过把较大的数据（模板类、联网下载的数据等）存到/Library/Caches目录，则同样可以解决问题。
2配置文件（Infoplist）检查
每个 APP 都使用Infoplist文件来存储以上的元信息，就是通常所说的 “属性列表”。IOS用Infoplist来决定bundle所显示的icon，当前app支持打开的文档类型，等等其它的信息。正如以上所提到的，Infoplist本身是一种结构化的文本文件，它包含了一些重要的配置信息。关于此部分的检查，我们通常关注如下方面的内容：
被拒条款
Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc（多任务应用只允许在后台运行如下相应的服务：VoIP，音频播放，地理位置，任务记录，本地提醒等。）
被拒案例
被拒原因描述：
We found that your app uses a background mode but does not include functionality that requires that mode to run persistently This behavior is not in compliance with the App Store Review Guidelines
We noticed your app declares support for VoIP in the UIBackgroundModes key in your Infoplist but does not provide any Voice over IP services
We recognize that VoIP can provide “keep alive” functionality that many app features would like to use However, using VoIP in this manner is not the intended purpose of VoIP, which, as indicated in the iOS Application Programming Guide, is that: “A Voice over Internet Protocol (VoIP) application allows the user to make phone calls using an Internet connection instead of the device’s cellular service”
It would be appropriate to add VoIP features or remove the “VoIP” setting from the UIBackgroundModes key
简评:
应用为了实现后台保持在线的功能，在 Infoplist 中定义的 UIBackgroundModes，间接声明了支持 VoiP 功能，实际应用被苹果认为并未按照 Voip 的定义去实现，导致被拒；从 Infoplist 移除了 UIBackgroundModes（VoIP）和相关代码后审核通过。总结，应用首次提交审核时，有争议的功能尽量先砍掉，先保证尽快上架。
3网络连接（***）
大多数App的审核服务器是部署在中国，然而苹果的iOS审核团队却又是在美国，他们进行审核时，使用的是美国网络，跨洲际的网络连接，难免会出现时延大、抖动、丢包等网络问题，因此被拒。
应对措施
为了提前验证App后台服务器基于此场景下的反应，预审团队采用美国***方式来模拟苹果审核团队的访问网络环境。
4Icon检查
苹果官方对iPhone、iPad、iPod等应用程序的icon有明确的要求：要求ipa包中必须包含180x180，120x120，76x76，152x152尺寸的PNG格式的icon（详见下表），并且不同尺寸的icon内容要一致。
5私有API检查
私有API是指放在PrivateFrameworks框架中的API，未公开的API是指虽然放在Frameworks框架中，但是却没有在苹果的官方文档中有使用说明、代码介绍等记录的API。
之前 APP Store 便下架了包括《爸爸去哪儿2》、《找你妹》在内的256款APP，原因是调用私有API，很明显，苹果明确不允许App使用这类API。
被拒条款：25
Apps that use non-public APIs will be rejected（使用非公开API的应用会被拒。）
被拒案例
被拒原因描述如下：
We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change
We found the following non-public API/s in your app:
descriptionWithCalendarFormat:
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple’s private APIs to avoid your application being flagged in future submissions
Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application If you do not have access to the library’s source, you may be able to search the compiled binary using “strings” or “otool” command line tools The “strings” tool can output a list of the methods that the library calls and “otool -ov” will output the Objective-C class structures and their defined methods These techniques can help you narrow down where the problematic code resides
We appreciate that you may have made the precautions in your code for using non-public APIs, however, there is no way to accurately or completely predict how an API may be modified and what effects those modifications may have For this reason, we do not permit the use of non-public APIs in App Store apps
简评：
这个条款被拒的描述文字比较多。先来看看苹果API的分类：
1) Published API（公开的API）：又称 Documented API（文档中记录的API）。是苹果通过 Cocoa Touch 向全世界第三方开发者公开的所有 API 。
2) UnPublished API（未公开API）：又称 Undocumented API（文档中未记录的API），是指虽然放在Frameworks框架中，但是却没有在苹果的官方文档中有使用说明、代码介绍等记录的API。按苹果的说法，未公开的API是还不够成熟，可能还会变动的API，等完全成型了后会变成公开的API，但是目前不对其提供承诺，就是系统版本升级后可能会失效。
3) Private API（私有API）：指的是SDK下的 PrivateFrameWorks框架下的API，真实存在于 Cocoa Touch 中。私有API是苹果明确规定不能使用的API，当然在越狱渠道没这个限制，比如91渠道。
被拒文字中的non-public APIs，后两种分类都算。源码中如果恰好定义了方法与非公开的API重名，也会导致被拒；比较常见的是，使用的第三方静态库中，包含了非公开的API，那么可以通过strings或otool命令来查找相关的API：
strings LibNamea | descriptionWithCalendarFormat
或
strings AppNameapp | descriptionWithCalendarFormat
其中app是编译结束后Build目录下的文件。
使用otool –ov LibNamea 输出Object-C类结构以及定义的方法。
应对措施
采用自动化工具扫描来实现，实现原理如下：
1、获取未公开库：基于iOS的SDK，dump出全库，全库减去私有库和公开库后，得到未公开库（non-public API）；
2、获取头文件方法和成员的列表：使用Otool等工具，对ipa的可执行文件进行反编译解析，获取头文件中方法和成员的列表；
3、与未公开库、私有库进行匹配：将列表中的方法和成员，分别与私有库和未公开库进行匹配，如未有匹配成功项，则扫描通过，如有匹配成功项，则扫描不通过（给出告警和API名称）。
6硬件与版本差异
iOS 2007年作为手机系统发布至今，已经陆续套用到iPod touch、iPad以及Apple TV等产品上，并更新了多个版本。而苹果的硬件也在不停地推陈出新，外部市场上也已经有比较多的产品硬件版本，面对如此之多的硬件及系统版本，怎么去保证提审版本的质量，是一直困惑测试和产品团队的大难题。
被拒案例
对应措施
1、与苹果关注同样的验收版本：推测苹果审核团队设备验收选型也会遵循原则：验收最新发布的两个系统版本，两个硬件版本。保证游戏可以在市场占有率最高的两个系统版本及硬件配置上可以流畅运行。
2、关注beta版本：苹果在新版本上线前会发布beta版本做少量测试，此时需要跟进beta版本，可以提前发现问题，避免突然版本发布造成措手不及。
总结：
1、实际上存储系统的检查是一套规范，遵循同系列理念，比如用户本地存储空间与苹果iCloud服务器存储的合理使用，节约空间；
2、Infoplist文件检查实际上是xml文件的键值检查，并且值检查关系是并列的。通过存储文件、plist用例的检查，基本避免了因该类原因被拒的情况；
3、通过自动化工具扫描是否调用了私有API， 苹果除了对提审版本扫描还会不定期对线上的版本进行扫描，所以别想着通过云控开关或者代码下发来绕开私有API。同样需要注意的是，不调用私有API，但跟私有API函数重名也会被apple认为违反了私有API规定。

以上就是关于如何提升iOS审核的通过率全部的内容，包括:如何提升iOS审核的通过率、、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！