三步走起 提升 iOS 审核通过率 上篇

2016年的第一天，各位小伙伴儿们，新年快乐~~~在过去一年里，负责 iOS 应用开发的同学们，想必已被 APP Store 的审核机制折磨心累不止。新的一年，又一轮审核即将来袭，你们做好准备了么？

为了帮助各位 iOS 应用开发的同学免受折磨，腾讯 Bugly 特邀互娱 iOS 预审团队通过大量的数据分析，对苹果的审核机制进行了一番总结，连夜赶稿写出提升 iOS 审核的通关秘籍（因为内容较多，因此分为上下两篇），来与大家分享。

经过互娱 iOS 预审团队近一年的数据监控，分析过往提审被拒的案例，我们对 iOS 的审核进行了缜密分析，统计出最常见的被拒原因：

通过以上案例，并结合《苹果应用商店审核指南》，大体可以将审核工作分为三块：客户端资源检查、应用内容检查、提审资源检查，我们将通过这三步来为您揭秘 iOS 审核的真相。

第一步：客户端检查篇

客户端检查的主要目的是通过客户端配置检查来保证客户端符合苹果的开发者规范以及其他更新的要求，包括存储系统、配置文件、网络连接（V**）、icon 检查、私有 API 检查，提审前的审核会覆盖这几个部分的各个测试点。

1.存储系统检查

苹果官方对用户数据存储有严格的规范，因此如果要通过审核，首先要了解一下苹果官方数据存储指引的相关内容：

被拒条款

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 5.6 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, e.g., 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 下产生了5.6 M的数据，说明不是用户自行创建并用于备份的，通过修改应用，在 Document 目录加一个不备份的属性（NSURLIsExcludedFromBackupKey）后审核通过。再来总结一下iOS 5 以后的存储规范：

● 只有那些用户生成的文档和其他数据或者是那些不能被你的应用所重建的数据应当保存在/Documents 目录内。这些数据文件将会自动的通过 iCloud 备份。

● 那些可以重新下载或者重新创建的数据应当保存在/Library/Caches 目录内。你可以把数据库缓存文件或者可下载的内容如杂志、报纸、地图应用的数据等放入缓存目录里（Caches directory）

● 临时需要的数据应该保存在/tmp 目录内。尽管这些文件不会备份到 iCloud 里，但记住不再需要它们时立即删除掉这些文件，这样它们就不会继续浪费用户设备的储存空间了。

● 使用“do not back up”属性指定不需要 iCloud 备份的文件（比如需要离线环境使用的文件；该属性能在任何目录下生效）。由于这些文件占用设备空间，所以应用需要有一套定期监控与清理这些文件的机制。

应对措施

本例中该应用未启用iCloud备份，如果启用了 iCloud 备份，则可以通过把较大的数据（模板类、联网下载的数据等）存到/Library/Caches 目录，则同样可以解决问题。

2.配置文件（Info.plist）检查

每个 APP 都使用 Info.plist 文件来存储的元信息，就是通常所说的 “属性列表”。iOS 用 Info.plist 来决定 bundle 所显示的 icon，当前 app 支持打开的文档类型，等等其它的信息。正如以上所提到的，Info.plist 本身是一种结构化的文本文件，它包含了一些重要的配置信息。关于此部分的检查，我们通常关注如下方面的内容：

被拒条款

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 Info.plist 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.

简评:

应用为了实现后台保持在线的功能，在 Info.plist 中定义的 UIBackgroundModes，间接声明了支持 VoiP 功能，实际应用被苹果认为并未按照 Voip 的定义去实现，导致被拒；从 Info.plist 移除了 UIBackgroundModes（VoIP）和相关代码后审核通过。总结，应用首次提交审核时，有争议的功能尽量先砍掉，先保证尽快上架。

3.网络连接（V**）

大多数 App 的审核服务器是部署在中国，然而苹果的 iOS 审核团队却又是在美国，他们进行审核时，使用的是美国网络，跨洲际的网络连接，难免会出现时延大、抖动、丢包等网络问题，因此被拒。

应对措施

为了提前验证 App 后台服务器基于此场景下的反应，预审团队采用美国 V** 方式来模拟苹果审核团队的访问网络环境。

4.Icon检查

苹果官方对 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。

被拒条款

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 LibName.a | descriptionWithCalendarFormat

或

strings AppName.app | descriptionWithCalendarFormat

其中.app 是编译结束后 Build 目录下的文件。

使用 otool –ov LibName.a 输出 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、Info.plist文件检查实际上是xml文件的键值检查，并且值检查关系是并列的。通过存储文件、plist用例的检查，基本避免了因该类原因被拒的情况；

3、通过自动化工具扫描是否调用了私有API， 苹果除了对提审版本扫描还会不定期对线上的版本进行扫描，所以别想着通过云控开关或者代码下发来绕开私有API。同样需要注意的是，不调用私有API，但跟私有API函数重名也会被apple认为违反了私有API规定。

如果您觉得我们的内容还不错，就转发到朋友圈，和小伙伴一起分享吧~

本文系腾讯Bugly独家内容，转载请在文章开头显眼处注明注明作者和出处“腾讯Bugly(http://bugly.qq.com)”

腾讯Bugly 最专业的质量跟踪平台

为您定期分享应用崩溃解决方案