App Store审核被拒求生指南

时间:2021-07-15 | 标签: | 作者:Q8 | 来源:产品研究社网络

小提示：您能找到这篇{App Store审核被拒求生指南}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的App Store审核被拒求生指南内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

对于曾在App Store提交应用审核的同学来说，相信很多人都有遇到过被拒的经历，且被拒的答复都是官方的通用答复模板，实际的被拒原因通常需要我们自己去猜测和琢磨。为了能更好的避开App Store审核的坑，以及踩坑后的填坑，本文选取部分常见的被拒条款进行总结分享，希望能帮到大家。

PS：详细的条款说明和规则见“App Store官方审核指南”

一、1.2 User Generated Content

条款1.2主要和APP的内容相关，被拒情况多发生在社交、社区类会有用户生成内容的APP上，解决该问题的核心是要让App Store知道你的应用能帮助用户处理不良内容。常见被拒原因和处理方法有：

1.缺少屏蔽或拉黑功能：当用户在APP上看到令人不适的内容时，应该允许用户屏蔽该内容，或者直接拉黑该内容的生产者以屏蔽所有该生产者的内容。所以，如果是因为该原因被拒，只需要在APP上添加相应的屏蔽或拉黑功能即可解决。

2.缺少举报功能：当用户在APP上看到不良内容时，应当允许iphone6危机公关用户对该内容进行举报，且平台应及时审查该内容，以减少该内容的影响范围。对应该被拒原因，需要增加举报功能，且在用户提交举报后，说明相应的审核周期。需要注意的一点是，服务方是否真的有人力审核被举报内容可根据具体情况来看，如果APP上提供的是一个假举报功能，则还是需要执行一次网络请求，因为App Store在审核时有一定概率校验功能的真伪性。

3.缺少联系方式：该功能用于帮助用户可以直接联系到APP服务方来处理内容相关的问题（版权类为主），所以需要在APP内增加联系功能，可以是站内信、邮箱和电话。

二、2.1 App Completeness

条款2.1主要和APP的完整度相关，常见的情况有两种：

1.出现明显的崩溃：如果是由于崩溃问题被拒，则只能按App Store审核团队提供的复现路径修复该问题后再重新提交。对于首次提交的应用，应尽可能杜绝明显的崩溃问题，避免给审核团队留下不好的映像而导致审核周期延长。

2.功能或代码不清晰问题：相对来说，大部分开发者收到2.1被拒都不是因为崩溃问题，而是2.1大礼包（Guideline 2.1–Information Needed），里面包含功能、支付、抄袭相关的内容。在收到2.1被拒大礼包时，开发者需要对照里面的各子条款来确定APP是否有出现说明里描述的问题，如果没有，则直接根据各子条款进行解释后回复App Store审核团队即可（有很大一部分开发者收到2.1大礼包时，其实并没有遇到其中的问题，针对条款解释清楚即可通过）；而如果有对应问题，则根据子条款的说明修改后再重新提交审核。PS：如果APP整体功能引导没有做好（新用户使用有难度），或者APP内有明显隐藏功能，则有比较大概率出现被拒的2.1大礼包。

三、2.3 Accurate Metadata

条款2.3则主要跟APP的描述相关，包括应用名、标题、描述、商店图和分类等方面。要避免由于该条款导致的被拒，最重要的是不要在上述地方使用和自身APP完全无关的内容，包括但不限于使用跟竞品有擦边球关系的文案或图案，特别是已注册品牌的内容；同时，App Store商店图和描述中应尽可能以展示应用的功能、用途和相关说明为主，减少擦边球内容。

四、3.1.1 In-App Purchase

条款3.1.1主要和APP内的支付相关，对于App Store（国外的Google Play也是类似标准）来说，所有虚拟物品、服务和货币的购买都需要走应用内购买来进行支付（游戏相关的功能、服务购买要求更严格）。大家提审被拒的原因基本都差不多，无非是虚拟物品交易时使用了手续费更低的第三方支付，而没有使用应用内购买（平台扣除30%手续费）来进行支付。对于该被拒原因，此处提供几种建议的处理方案（违规风险依然存在，可自行判断后确定是否使用），但首先，需要先在APP内按照官方的要求设计一套合规的应用内购买支付方式，另外再提供额外的绕开审核的处理方法：

1.在接入微信支付和支付宝支付时，一定要避免在代码中出现相关的敏感关键字，如：WeChat Pay、Alipay等，可以自行替换成内部能够理解的其他字段。

2.采用服务器开关控制的方式来控制支付方式的下发，同时APP本地使用默认合规的应用内购买支付方式，在提交审核期间，关闭服务器开关控制，本地仅使用合规方案，待审核通过后再开启使用替代方案。

3.使用方案2还是可能在审核通过后再次被查处，所以，相对更稳妥一点的方案，可以考虑根据用户类型来控制支付方式的下发。如自然用户（App Store官方即为自然用户）只下发合规方案，而买量用户则下发替代方案，以此来规避审核风险。

4.APP本身还是提供合规的应用内购买支付方式，但如果用户绑定了手机号，可通过手机号判断用户归属的国家，中国区用户可通过手机短信引导使用支付宝或微信在H5页面支付（可降价促销），非中美用户可引导在H5页面用PayPal支付。

五、4.3 Spam

条款4.3则主要跟换肤、抄袭有关，一般来说都是由于代码、UI或功能与另外一个应用相似或高度相似导致被拒，其中代码和UI导致被拒的可能性更高。当然，不管是换肤马甲包还是抄袭竞品被拒，首先我们需要确定的是机审拒绝还是人工审核拒绝。下面从三个层面分析并提供解决思路：

1.代码层面：判断是否是代码层面的问题比较简单，一般可根据客户端上传的用户行为统计数据和App Store Connect后台的审核时间进行判断，取APP进审到被拒时间段的美国（不管发布的是哪个国家的应用，统一都是有美国的审核人员进行审核）用户行为数据进行分析，如果期间的行为数据只有APP的启动和退出，而没有其他的功能路径统计，则完全可以认定为机审拒绝，这时就基本可以确定是代码层面的问题。如果是做马甲包，则需要重点排查代码层面的相似度问题，增加垃圾代码和修改类名可以在一定程度上规避该问题；另一方面，可以从接入的SDK方面处理，对于一些可以自己实现的SDK功能在马甲包上尽可能自己实现，同时，如果有不同第三方提供了类似的SDK，则可在马甲包上接入另外的SDK。

2.UI层面：排查方法类同上面如果机审通过，而人工审核拒绝，则只能是UI或者功能层面的问题，相对来说，UI层面会比功能层面查的更严。这方面的处理，核心是规避和主包或者竞品的UI相似性，重点修改根据用户行为统计判断的审核人员查看的页面，原则上UI可以丑（即便开始的时候丑一点，但后面上线后再修改通过的概率更高），但不能雷同。

3.功能层面：如果是由于这方面的原因被拒，则后续再成功上线的机会就比较渺茫，所以功能层面的重点是防患于未然，而不是被拒后的补救。所以，在初始上线前，可以先选择一个和主包有明显差异但又能在后续联系在一起的功能方向，将这个差异明显的功能先当成应用的核心功能进行发布，后续再逐步添加主包的功能进行补充。

当然，不管从哪个维度进行处理，需要先明确的几点是：①主包和马甲包需要在不同主体下的账号上发布，不能在同账户下发布两个相似应用，除非功能有明显区别（即便有明显区别还是建议先再另外一个账号发布，等整体功能稳定且有明显差异方向后，再迁移到同一账号下）；②如果由于条款4.3被拒，审核时间会延长，且每拒一次都会在原审核时间上叠加延长，所以，在修改时需要尽可能大的改动后再重新提审，同时可在后台人工联系App Store审核团队请求电话解答，切不可操之过急；③如果由于条款4.3被拒超过三次，后续再过审的几率几乎为0，建议果断放弃，将应用从后台删除后更换一个新的主体账号发布。

六、5.1.1 Data Collection and Storage

条款5.1.1主要和APP收集的数据相关，被拒原因和修改方向都比较明确，常见的情况有以下几种：

1.隐私条款说明不规范：如果是条款方面的问题，可以重点对比下竞品的隐私条款包含的内容，然后再据此跟开发和法务沟通后修改即可。

2.权限获取说明不规范：因为条款5.1.1被拒的开发优科豪马改胎号危机公关者，大多是由于该原因，可根据苹果影视广告专业官方答复的截图，修改权限的获取文案即可。权限获取时，在弹窗上说明获取该权限的具体用途。

3.强制登录问题：对于需要用户登录后才允许使用功能的APP，需要设定好登录的优先级。例如：根据App Store官方说明，应用内购买应允许非注册用户使用。所以，如果功能设计为非登录状态即可看到应用内购买项目，点击后要求用户注册后才能支付或使用，这就可能被拒。而如果调高登录优先级，在用户未登录状态无法看到应用内购买项目，登录后才能看到相应入口，就能有效的规避该问题。

七、可能导致被拒的操作

前文写的主要是“因为对应条款被拒”后的相关分析和补救方法，此处再补充一些可能导致被拒的常见操作，希望大家能有效避坑。

1.带有占位符内容，在应用程序中出现未完成的图片或文本等内容；