那些年提交AppStore审核踩过的坑 _那些年

古人学问无遗力，少壮工夫老始成。这篇文章主要讲述那些年提交AppStore审核踩过的坑相关的知识，希望能为你提供帮助。
此文刚刚上了CocoaChina的首页：那些年提交AppStore审核踩过的坑欢迎围观，谢谢大家支持。
//add by 云峰小罗，2016.08.04
做ios开发近5年了，每次提交版本时不可谓不小心翼翼，如履薄冰，但是还是难免踩到了一些坑。苹果的官方文档（AppStore审核条款）这里就不罗列了，太冗长繁琐了，而且大部分是一般app都不会触碰的到的，今天我主要想以自己的亲身经历，跟大家回顾一下这些年我提交AppStore审核时踩过的坑，并且针对如何避免给出一些tips供大家参考。大神请忽略，专家请轻拍。
1、未遵守苹果iOS APP数据储存指导方针。
如果你的App有离线数据下载功能，尤其需要关注这一点。因为离线数据一般占用存储空间比较大，可以被重新下载和重建，但是用户往往希望系统存储空间紧时也依然能够妥妥的存在着，不会被IOS系统自动清理掉。所以不能放在/Library/Caches 目录下（该目录在系统空间紧张时可能会被iOS系统清除）。那就只能放在主目录/Documents 或主目录/Library/自定义文件夹下，这样才不会被iOS系统自动清理掉。但是这些数据可能会很大，如果放在主目录/Documents 或主目录/Library/自定义的文件夹下，会被iCoud自动同步，那么用户需要为了同步消耗不少流量，苹果可能会因此拒绝你的应用上架。所以需要在程序中给自定义的目录设置“do not backup”属性。

关于数据存储需要注意的点，总结在下面：
关键数据
内容：用户创建的数据文件，无法在删除后自动重新创建
路径：主目录/Documents
管理：iOS系统即时遇到存储空间不足的情况下，也不会清除，同时会备份到iTunes或iCloud中
缓存数据
内容：可用于离线环境，可被重复下载重复生成，即使在离线时缺失，应用本身也可以正常运行
路径：主目录/Library/Caches
管理：在存储空间不足的情况下，会清空，并且不会被自动备份到iTunes和iCloud中
临时数据
内容：应用运行时，为完成某个内部操作临时生成的文件
路径：主目录/tmp
管理：随时可能被iOS系统清除，且不会自动备份到iTunes和iCloud，尽量在文件不再使用时，应用自己清空，避免对用户设备空间的浪费
离线数据
内容：与缓存数据类似，可以被重新下载和重建，但是用户往往希望这些数据即使在存储紧张时也不会被系统自动删除
目录：主目录/Documents 或主目录/Library/自定义的文件夹
管理：与关键数据类似，即使在存储空间不足的情况下也不会被清除，应用自己应该清除已经不再使用的文件，以免浪费用户设备空间。需要设置”不备份到iCoud" ，否则会审核不过。

2、未提供测试账号
如果你的App有部分功能需要登录才能使用，那么你需要再提交审核时，勾选演示账户，并提供对应信息，如下图：

文章图片

测试账号填写现在很多app为了更方便快捷，防止用户忘记密码，都采用手机号+验证码的方式，这样的话就没有办法给苹果提供演示账户了，除非账户系统后台做修改提供支持。这种情况，就不需要勾选演示账户了，但是要在备注信息里跟苹果好好解释一下，说我们也是为了提升用户体验的，所以对账户系统做了改进，用户有手机就能登录，不需要注册啥的，如下图。如果你啥也不说的话，那就乖乖等着被拒吧。

文章图片

测试账号说明3、跟相关硬件配合使用的app，未提供演示视频。
这里指的硬件是不需要MFi认证的，通过BLE（低功耗蓝牙）或者WiFi连接的硬件。直接在备注里提供相关功能的演示视频即可，如下图。

文章图片

硬件连接演示视频演示视频需要把完整的连接过程操作以及连接硬件之后跟硬件相关的功能演示都包含在内。从截图可以看到我的“裤宝”演示视频我是直接放在优酷上了。所以并不像传闻中那样，需要FQ放到YouTube上，直接放优酷土豆或者百度网盘都行。也不需要用英文，用中文即可。
4、跟相关硬件配合使用的app，未提供PPID.(Product Plan ID )
如果你的App是需要跟通过MFi认证的硬件进行交互，即使用了EA框架（ExternalAccessory.framework），配置了协议字符串（Supported external accessory protocols），那么你需要在备注信息里提供PPID。

文章图片

ppid说明很多时候，我们的App可以同时适配很多型号的硬件，每个型号的硬件对应的PPID不一样。如果AppStore提交审核通过之后，又新增了一款型号硬件支持怎么办呢？是否需要单独发一个版本，把对应的PPID增加上去了？答案是不需要，因为App支持的PPID列表信息是放在备注信息里面的，往列表中新增PPID并不需要修改到二进制文件信息，苹果在这里也比较人性化，可以在不提交新版本的情况下增加PPID信息。
5、使用了后台定位服务，但是没有具体说明原因
之前使用后台定位功能的app都是只需要在在Info.plist中配置 Required background modes -App registers for location updates 即可.但是从2016年的某个时候开始苹果突然要求如果App要使用定位功能，除了程序里做配置，还需要在界面上显式告诉用户你的后台定位是用来干啥的，否则你就会收到类似下面的邮件。

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.

要修改也可以简单，根据你的app需要在info.plist中配置，NSLocationAlwaysUsageDescription或者NSLocationWhenInUseUsageDescription字段说明。如下图

文章图片

定位目的说明6、上传的屏幕快照跟App具体使用截屏相差太远
AppStore提供的屏幕快照功能是为了用户在未下载时可以直观的了解这个App的功能、界面大概是什么样的。所以苹果也允许开发者对屏幕截屏做一些加工美化，并不一定要是原始截屏。但是这里有个限度，就是不能相差太远，具体尺度苹果没有给出量化标准。公司项目中有个大版本上线了一个比较大的新功能，为了突出宣传这个功能，设计师就重新设计了一套非常Q版的功能演示截图。结果上传后被苹果告知，屏幕快照不符合App本身的功能。
以上这些是本人在AppStore审核时亲自踩过的一些坑，当然还有很多坑，我和我的团队注意到了所以努力避免了，但是个人认为也是非常需要注意的，我简单列在下面供大家参考。

使用未公开的API被发现
使用和系统接近的图标
界面太丑或者交互太过复杂
不稳定，容易崩溃
跟应用市场上其他App太过雷同
App内有检测更新
出现第三方操作系统的名字或图标
测试不充分，某些App声明支持的操作系统版本有兼容性问题

文章图片

tips我们说了这么多踩过的坑，或者差点踩过的坑，无非就是想在以后App开发中尽可能的避免。这里介绍本人的一些经验总结，供大家参考。
1、预防在先
对产品经理规划的功能，首先需要判断是否在技术上可以实现，或者说在不使用非公开API的前提下实现。因为很多时候，即使你通过函数名动态拼接等技术手段在提交审核时躲过API扫描，但是也难免被苹果从功能上发现或者被竞争对手举报。然后对交互设计和UI效果图需要有自己的判断，界面不能太丑，交互不能太复杂，不能使用跟系统太过雷同的Icon。
2、发版前过checklist
每个项目都需要沉淀发版前的checklist，把之前踩过的坑进行备忘，也可以通过网络资讯等手段了解最近时间被拒的一些主要原因，把可能跟自己APP相关的部分进行备注，然后在发版前逐条检查一遍。
3、预提交AppStore审核
如果也预防了，发版前也过了checklist，但是有时候还是难免百密一疏有所遗漏，特别是新功能较多的版本。这里我要重点推荐的就是预提交AppStore审核。项目的版本都是有发版周期的，一般在发版前一周左右App版本基本稳定，只是还需要修改一些bug并回归测试。这个时候完全可以先提交一个版本到AppStore去审核，反正版本号是用不完的，只要不占用产品经理定的版本号就行。预提交审核有什么好处呢？
(1)可以帮助暴露潜在的问题。
这个版本可能开发了一些新功能，然后有些地方可能没有考虑到审核相关的风险。如果等待项目都要结束正式发版时才暴露出来，就追悔莫及了。
(2)在迫不得已的情况下，可以试探一下苹果的界限。
苹果审核条款其实很多时候是没有一个量化标准的，比如屏幕快照不能跟App具体使用时的截屏相差太远，拿到UI设计师给到屏幕快照时，我们有时候也没有办法确定到底是否真的符合苹果的规范，但是没有关系，我们先提交一个版本试一试就知道了；还有再比如前段时间，苹果要求6月1号以后提交的App都要支持IPV6-Only的网络。但是由于历史原因，项目中有个功能用的是第三方的SDK，他们没有办法在我们发版前提供新的支持IPV6的版本。然后我看网上也有人分享说苹果对这个要求并不是非常严格，只需要在iOS9下主要功能能支持IPV6就行了。当然作为项目负责人，肯定也不能说直接把这个功能砍掉不要了，亦或轻信网友所言忽视风险。怎么办呢？赶紧先预提交一个版本试一下再做决定。结果是确实可以通过审核，所以最终版本没有砍掉这个功能，保证了产品的完整性上线了。
4、关于AppStore加急审核
如果经过前面的努力，你还是被拒了，或者App的发布要赶上某个时间运营节点，但是由于各种原因导致预留给App审核的时间太少了。这个时候你需要使用到苹果的加急审核通道。
你在百度里搜索iOS加急审核，你会发现有很多宣称可以帮你快速审核的人，24小时通过审核，审核通过后付款，不通过不要钱。如果你不知道苹果有官方的加急审核功能，你就很容易被这些空手套白狼的人所骗，而且收费都是5000RMB起步。那我真的很想对你说，找我吧，给你友情价打5折。
苹果的加急审核如何使用呢？在iTunesconnect页面，点击右上角的“?”图标，在弹出菜单中选择“联系我们”，

文章图片

联系我们然后在Contact Us页面，选择“App Review” —> “App Store Review” —> ” Request Expedited Review”,

文章图片

加急审核选项最后在表格里填写相关信息，其中最重要的写你需要加急审核的原因。一般是写要赶某个重大节日运营节点，或者紧急修复某个严重的闪退问题，然后注明闪退现象复现的详细步骤，就可以了。
关于具体加急审核有没有次数限制，次数是跟App相关还是跟开发账号相关，苹果并没有官方的说明。但是可以肯定的是，网上传闻一年只有两次加急审核的机会是不正确的。不过为了让好钢用在刀刃上，还是慎用这个功能，以防到时真的有需要加急审核时却得不到响应。
从今年上半年开始，app审核时间大大缩短了，一般都不需要用到这个功能了。百度CarLife 最近几个版本都是3天就通过审核了，尤其是最新的支持EAP连接的版本V2.1.0，一个晚上就审核通过了。
毛主席告诉我们“与天奋斗，其乐无穷！与地奋斗，其乐无穷！与人奋斗，其乐无穷！”，但是作为iOS开发者，跟苹果奋斗，还是小心谨慎为好。最后提一句，如果你知道你的app存在某个审核风险，但是通过了苹果审核，那么不要存在侥幸心理，请尽快修改。因为毕竟苹果是人工审核，这个版本过了可能是审核人员心情好，并不代表下个版本审核时心情也这么好。
【那些年提交AppStore审核踩过的坑】其实想想最近的广电总局手游审查新政，对AppStore的审核规则也就没有啥可以抱怨的了。