(2023)苹果2.1应用完整性问题自查笔记

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. 多线程编程导致的卡死问题,编程人员应该尽量简化编程模型,不要出现过于复杂难以驾驭的多线程交互。

还有补充的欢迎留言。

更多阅读

联系我

公众号 wechat
风海铜锣 xq2723866

咨询星球

移动开发者联盟加入指引

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

苹果开发者30天封号笔记

猜你喜欢

转载自blog.csdn.net/madaxin/article/details/130585102