1、未遵守苹果 iOS APP 数据储存指导方针
如果你的 App 有离线数据下载功能，尤其需要关注这一点。因为离线数据一般占用存储空间比较大，可以被重新下载和重建，但是用户往往希望系统存储空间紧时也依然能够妥妥的存在着，不会被 iOS 系统自动清理掉。所以不能放在 /Library/Caches 目录下（该目录在系统空间紧张时可能会被 iOS 系统清除）。 那就只能放在主目录 /Documents 或主目录 /Library/ 自定义文件夹下，这样才不会被 iOS 系统自动清理掉。但是这些数据可能会很大，如果放在主目录 /Documents 或主目录 /Library/ 自定义的文件夹下，会被 iCoud 自动同步，那么用户需要为了同步消耗不少流量，苹果可能会因此拒绝你的应用上架。所以需要在程序中给自定义的目录设置 “do not backup” 属性。
#import "sys/xattr.h" // 对指定的文件路径及路径文件夹内的文件夹和文件设置不备份到 iTunes 和 iCloud 属性 - (BOOL)addSkipBackupAttributeToItemAtURL:(NSURL *)URL { NSString *path = URL.path; const char *filePath = [path fileSystemRepresentation]; const char *attrName = "com.apple.MobileBackup"; u_int8_t attrValue = 1; int result = setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0); return result == 0; } - (BOOL)addSkipBackupAttributeToItemAtPath:(NSString *)path { const char *filePath = [path fileSystemRepresentation]; const char *attrName = "com.apple.MobileBackup"; u_int8_t attrValue = 1; int result = setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0); return result == 0; }关于数据存储需要注意的点，总结在下面：
1、关键数据
内容：用户创建的数据文件，无法在删除后自动重新创建
路径：主目录 /Documents 管理：iOS 系统即使遇到存储空间不足的情况下，也不会清除，同时会备份到 iTunes 或 iCloud 中2、缓存数据
内容：可用于离线环境，可被重复下载重复生成，即使在离线时缺失，应用本身也可以正常运行
路径：主目录 /Library/Caches 管理：在存储空间不足的情况下，会清空，并且不会被自动备份到 iTunes 和 iCloud 中3、临时数据
内容：应用运行时，为完成某个内部操作临时生成的文件
路径：主目录 /tmp 管理：随时可能被 iOS 系统清除，且不会自动备份到 iTunes 和 iCloud，尽量在文件不再使用时，应用自己清空，避免对用户设备空间的浪费4、离线数据
内容：与缓存数据类似，可以被重新下载和重建，但是用户往往希望这些数据即使在存储紧张时也不会被系统自动删除
目录：主目录 /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。
很多时候，我们的 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 本身的功能。
7、其它一些被拒原因
使用未公开的 API 被发现
使用和系统接近的图标
界面太丑或者交互太过复杂
不稳定，容易崩溃
跟应用市场上其他 App 太过雷同
App 内有检测更新
出现第三方操作系统的名字或图标
测试不充分，某些 App 声明支持的操作系统版本有兼容性问题
8、经验总结
- 我们说了这么多踩过的坑，或者差点踩过的坑，无非就是想在以后 App 开发中尽可能的避免。这里介绍一些经验总结，供参考。
8.1 预防在先
对产品经理规划的功能，首先需要判断是否在技术上可以实现，或者说在不使用非公开 API 的前提下实现。因为很多时候，即使你通过函数名动态拼接等技术手段在提交审核时躲过 API 扫描，但是也难免被苹果从功能上发现或者被竞争对手举报。
然后对交互设计和 UI 效果图需要有自己的判断，界面不能太丑，交互不能太复杂，不能使用跟系统太过雷同的 Icon。
8.2 发版前过 checklist
- 每个项目都需要沉淀发版前的 checklist，把之前踩过的坑进行备忘，也可以通过网络资讯等手段了解最近时间被拒的一些主要原因，把可能跟自己 APP 相关的部分进行备注，然后在发版前逐条检查一遍。
8.3 预提交 AppStore 审核
如果也预防了，发版前也过了 checklist，但是有时候还是难免百密一疏有所遗漏，特别是新功能较多的版本。这里要重点推荐的就是预提交 AppStore 审核。项目的版本都是有发版周期的，一般在发版前一周左右 App 版本基本稳定，只是还需要修改一些 bug 并回归测试。这个时候完全可以先提交一个版本到 AppStore 去审核，反正版本号是用不完的，只要不占用产品经理定的版本号就行。
预提交审核有什么好处呢？
1）可以帮助暴露潜在的问题。
- 这个版本可能开发了一些新功能，然后有些地方可能没有考虑到审核相关的风险。如果等待项目都要结束正式发版时才暴露出来，就追悔莫及了。
2）在迫不得已的情况下，可以试探一下苹果的界限。
- 苹果审核条款其实很多时候是没有一个量化标准的，比如屏幕快照不能跟 App 具体使用时的截屏相差太远，拿到 UI 设计师给到屏幕快照时，我们有时候也没有办法确定到底是否真的符合苹果的规范，但是没有关系，我们先提交一个版本试一试就知道了；还有再比如前段时间，苹果要求 6 月 1 号以后提交的 App 都要支持 IPV6-Only 的网络。但是由于历史原因，项目中有个功能用的是第三方的 SDK，他们没有办法在我们发版前提供新的支持 IPV6 的版本。然后我看网上也有人分享说苹果对这个要求并不是非常严格，只需要在 iOS9 下主要功能能支持 IPV6 就行了。当然作为项目负责人，肯定也不能说直接把这个功能砍掉不要了，亦或轻信网友所言忽视风险。怎么办呢？赶紧先预提交一个版本试一下再做决定。结果是确实可以通过审核，所以最终版本没有砍掉这个功能，保证了产品的完整性上线了。
8.4 关于 AppStore 加急审核
如果经过前面的努力，你还是被拒了，或者 App 的发布要赶上某个时间运营节点，但是由于各种原因导致预留给 App 审核的时间太少了。这个时候你需要使用到苹果的加急审核通道。
你在百度里搜索 iOS 加急审核，你会发现有很多宣称可以帮你快速审核的人，24 小时通过审核，审核通过后付款，不通过不要钱。如果你不知道苹果有官方的加急审核功能，你就很容易被这些空手套白狼的人所骗，而且收费都是 5000RMB 起步。
苹果的加急审核如何使用呢？在 iTunesconnect 页面，点击右上角的 “?” 图标，在弹出菜单中选择 “联系我们”。
然后在 Contact Us 页面，选择 “App Review” —> “App Store Review” —>” Request Expedited Review”。
最后在表格里填写相关信息，其中最重要的写你需要加急审核的原因。一般是写要赶某个重大节日运营节点，或者紧急修复某个严重的闪退问题，然后注明闪退现象复现的详细步骤，就可以了。
关于具体加急审核有没有次数限制，次数是跟 App 相关还是跟开发账号相关，苹果并没有官方的说明。但是可以肯定的是，网上传闻一年只有两次加急审核的机会是不正确的。不过为了让好钢用在刀刃上，还是慎用这个功能，以防到时真的有需要加急审核时却得不到响应。
从 2016 年上半年开始，App 审核时间大大缩短了，一般都不需要用到这个功能了。百度 CarLife 最近几个版本都是 3 天就通过审核了，尤其是最新的支持 EAP 连接的版本 V2.1.0，一个晚上就审核通过了。