App Rejected -Guideline 2.1 – Performance – App Completeness

苹果审阅使用完好性问题。

一般案牍以这种方式开头：

We discovered one or more bugs in your app when reviewed on ……

一般此处会给出具体的设备和网络环境。

之后，会有一个 Specifically：

Specifically, we were not able to ……

后面会有一段一般性主张：

To resolve this issue, please run your app on a device to identify any issues, then revise and resubmit your app for review.

If we misunderstood the intended behavior of your app, please reply to this message in Resolution Center to provide information on how these features were intended to work.

网络环境

网络的问题并不复杂，只需自己做了网络测验基本就知道究竟是自己的问题，还是苹果的问题。

WIFI，蜂窝网络，弱网络等测验。一般就这几种状况。

一般网络基本测验可以采取这几个过程：

1. 封闭 WIFI，测验使用在无网络环境下的交互表现。（有没有做必要的过错交互）
2. 弱网络测验，可以用各种古怪的方案，最简略粗犷的方法是离信号远一点测验。
3. 有条件的话就架起海外地区的网络环境。

另外，app 做的过错超时时间设置不宜过短。

2.1 最中心的审阅要求：

1. 功用完好，不要有点击无呼应的按钮。
2. 功用契合预期，不能呈现歧义功用。
3. 没有溃散，基本要求。
4. 不能呈现严重卡顿。

账号登录

登录问题导致的 2.1 十分常见。

☆ 第三方登录要做足条件判别和交互

假如是微信和 QQ 登录，应检测本地客户端是否装置，并做出提示交互。不应该假定用户现已本地装置了，例如苹果审阅测验设备是没有 QQ 的，假如点击登录没反应，会断定 2.1 驳回。

☆ demo 账号数据

涉及账号相关的内容类产品假如好几个页面展现列表为空白页，也或许会被驳回。处理方法是为空白页规划可读性好的页面，另一个方法更有效，为 demo 账号规划对应的填充数据，让每个页面都饱满起来。

交互误导

开发处理产品交互逻辑时要仔细，最常见的是和网络有关的 Loading 控件的展现问题（咱们俗称的“菊花控件”）。

在某些网络延迟下，Loading 控件没有处理好展现和消失的逻辑。就容易呈现画面展现了 Loading 还在的 Bug。

这里我有一个简略的思路供大家参阅，就是假如苹果以为某个点击没有呼应，而你是产品的负责人而非程序员（假如你是程序员，那么直接看代码梳理即可），那么不要简略的问程序员“这个有没有完好实现”。而是要要求程序员依据按钮的点击状况列出一个完好的呼应链路来。

例如，假设该按钮是“联络邮箱”，那么点击呼应的检查示例如下：

1. 假如本地没有邮箱，弹出弹框，提示用户“未找到本地邮箱”。
2. 假如本地有邮箱：
   2.1 是否在生成默许邮箱内容时产生BUG
   2.2 是否呼应了点击取消时的退出
   2.3 检查邮箱控件一切事件回调的逻辑
3. 点击按钮是否有日志发送逻辑
   3.1 假如存在日志发送，是否确保了发送是在非主线程执行
   3.2 其它细节

设备问题

由于审阅的测验设备一般是 iPad，所以产品针对 iPad 的测验必不可少。

一般来说测验设备最好是：5.5 英寸显示屏设备一个，6.5 或 6.7 英寸显示屏设备一个，任何较新的 iPad 设备一个。

这里有一点需求着重的，即有一些 iOS API 的调用逻辑，是只对 iPhone 设备适用，而对 iPad 不适用的，且在调用时苹果不会给出警告，最后结果是 iPhone 正常，而在 iPad 上没有正确调用则会溃散。（最典型的是 iOS 原生的 UIAlertViewController。）

假如你的产品的目标设备仅仅 iPhone，那也有必要考虑对 iPad 模仿环境的兼容，由于即便在 iPhone 上测验没问题，在 iPad 环境下依然或许存在界面布局等方面的差异，而且假如不及时发现，代码写多了的话后续更难排查。

付出问题

付出问题涉及到服务器验证，程序员不熟悉和沙箱环境等细节，所以犯的过错千奇百怪，比较繁琐。这里就不展开了。

但是现在遇到的事例有很大一部分是苹果审阅的问题。

有时候苹果审阅没有仔细测付出功用，加上苹果的付出体系有时候真的会抽风，而审阅把锅直接甩给开发者。

所以假如是这种状况，提供具体的测验阐明，视频示例，并留下电话和苹果交流，一般都能定位到具体问题。

其它

还有许多稀奇古怪的 Bug 要注意。事实上 2.1 是个“好拒”，相当于苹果审阅为你充当了一次测验人员，为了你的产品品质做了保证。下面再列几条 2.1 问题的常见情形。

1. 发动屏幕卡死。这种一般是代码初始化隐藏了bug 。
2. 像 flutter，RN 等跨渠道代码，存在部分兼容性问题，导致在 iOS 部分环境下表现不一致（这种最麻烦，需求许多奇技淫巧处理）。
3. 多线程编程导致的卡死问题，编程人员应该尽量简化编程模型，不要呈现过于复杂难以驾御的多线程交互。

还有补充的欢迎留言。

更多阅览

联络我

移动开发者联盟加入指引

近期大规模 4.3，2.3.1 问题小结

苹果开发者30天封号笔记