导读：iOS 应用开发者在将自己的应用上架到苹果 App Store 的过程中，常常遇到因各种理由被苹果拒审的情况，一旦被拒，就需要花费不少时间来整改。苹果官方为 App 上架设定了《App Store 审核指南》，旨在保证 App Store 上应用的质量，但同时上架审核也对希望发布自己应用的开发者造成不少困扰。本文将介绍审核被拒的危害、App Store 上架审核所面临的困难，并分享实际的拒审案例。
01 拒审的危害
成本增加
App 提审后，苹果需要一些时间来处理，少则几天，多则十几天。一旦开发者提交的 App 审核被拒，在内部就要整改代码、重新验收测试，无疑增加了研发成本和测试成本。此外，开发者还要重新等待苹果提审排队，更糟的是，如果触犯了一些苹果较为重视的条款，苹果会延长审核周期以便更仔细地审查该 App，这严重拖延了版本过审时间，影响了项目的规划，付出大量时间成本。
连带影响
如果开发者的某个 App 被苹果拒审，影响的不只是这一款 App，该开发者账号以及相关账号下所有 App 都会被苹果检查是否存在类似问题，如有则将一起下架。在更为极端的情况下，App 由于一些重要条款连续被拒，可能会导致开发者账号被封禁。
02 过审面临的困难
开发者上架 App Store 之所以遇到阻碍，有以下几点重要因素：严格而庞杂的审核标准、回复的不透明、半自动化审核。
严格而庞杂的审核标准
苹果于 2010 年公开了审核 App 所遵循的标准《App Store 审核指南》，并且随着时间推移不断更新该标准。标准中涵盖安全、性能、商务、设计、法律五大方面，要求细致而严格。开发者如果没有对标准进行深入了解，或者没有及时对标准进行跟进，很容易无意中违反某些条款，导致审核被拒。
回复的不透明
如果 App 被拒，苹果会给出拒审回复，说明 App 由于违反哪一条款而被拒绝，但是苹果的回复往往不会特别具体透明，开发者常常不知道自己的 App 到底是哪个地方违反了苹果所援引的条款。因此，大量被拒审的开发者只能通过猜测违规处、试探性改正并重审的方式来解决。
半自动化审核
面对海量的 App 审核需求，苹果的审核人力显得捉襟见肘，因此苹果采用人审与机审结合的审核方式，只有机审通过，才会进入人审的环节。因为机审的标准相对人审更为统一，所以要尽量在提交审核前保证机审能通过，如果因为机审被拒，则会无谓地浪费开发者的时间。
03 拒审案例
私有 API
苹果将自身系统的 API 划分为公共 API 和私有 API，其中公共 API 可供 App 开发者使用，私有 API 则只允许苹果使用，如果 App 开发者使用私有 API，那么该 App 会被拒绝上架。例如，有些开发者希望通过以下代码获得手机上已安装的应用列表：
+ (void)installedApplications {
Class aw = objc_getClass("LSApplicationWorkspace");
NSObject* workspace = [aw performSelector:NSSelectorFromString(@"defaultWorkspace")];
NSArray *apps = [workspace performSelector:NSSelectorFromString(@"allInstalledApplications")];
Class ap = objc_getClass("LSApplicationProxy");
for (int i = 0; i < apps.count; i++) {
NSObject *curapp = apps[i];
if ([curapp isKindOfClass:ap]) {
NSString *appBundleId = [curapp performSelector:NSSelectorFromString(@"applicationIdentifier")];
NSString *appName = [curapp performSelector:NSSelectorFromString(@"localizedName")];
NSLog(@"BundleId: %@", appBundleId);
NSLog(@"Name: %@", appName);
}
}
}
苹果的《App Store 审核指南》第 2.5.1 条规定：App 仅可使用公共 API，并且必须在当前发布的 OS 上运行。由于 LSApplicationWorkspace 类中的 allInstalledApplications 方法属于私有 API，该 App 遭到了苹果拒审。苹果没有公开私有 API 的范围，客户难以确知自身 App 存在哪些私有 API，易盾的上架预审工具可自动对私有 API 进行扫描，帮助客户定位。
第三方支付
App 开发者常需要在 App 中提供付费购买的项目，因此需要接入第三方支付平台。例如，许多手机游戏设置了付费的道具，有的开发者在实现道具购买时，接入第三方支付，结果却被苹果拒绝上架 App Store。
在此案例中，App 遭到拒绝的原因在于苹果提供了“App 内购买”机制（简称内购），并在《App Store 审核指南》第 3.1.1 条规定：如果你想要在 App 内解锁特性或功能 (解锁方式有：订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等)，则必须使用 App 内购买项目。同时，第 3.1.3(e) 条还规定：如果 App 允许用户购买将在 App 之外使用的实体商品或服务，则必须使用 App 内购买项目以外的购买方式来收取相应款项，如 Apple Pay 或传统的信用卡入口。这些规定意味着，在 iOS App 中购买虚拟物品必须通过内购机制进行，不允许使用第三方支付，而购买实体物品则必须采用第三方支付。易盾的专业上架预审团队可对第三方支付的使用进行全面排查，确保 App 符合苹果上架规定。
热更新
热更新是一种代码修补技术，开发者通过热更新可以达到无需发布新版本就能对 App 功能进行更新的效果。热更新技术在安卓系统十分流行，有的开发者在 iOS 上想使用这一技术来实现“实时修复 bug”，因为有时一些 bug 等到下一次新版本发布再修复就太慢了，而热更新则可以实时从服务器拉取最新版本的代码运行。然而，这一行为却导致 App 被苹果方面拒绝上架。
苹果在《App Store 审核指南》第 2.5.2 条规定：App 应自包含在自己的套装中，不得在指定容器范围外读取或写入数据，也不得下载、安装或执行会引入或更改 App 特性或功能的代码，包括其他 App。苹果设置该条款是为了防止 App 在审核期间和实际上架以后下载拉取不同的代码，从而导致审核时无法看到 App 的“真面目”，热更新技术恰恰属于该条款明令禁止的范围。易盾的上架预审团队结合易盾上架预审工具自动化检测，可排查 App 是否存在热更新，并协助用户解决相关问题。
04 结语
苹果对 App Store 上架要求严格，许多 iOS App 开发者由于对繁杂的上架审核标准不够熟悉而在审核时遇到阻碍，为避免上架过程中耗费不必要的时间，可以在上架前选择专业团队来对 App 进行上架预审，减少 App 上架被拒的风险。