前言
Other 问题是老生常谈了，但是因为苹果政策一直在变，所以有时候老问题经常出新花样。最近不少开发者小伙伴“莫名其妙”的遭遇了Other，但是其实大家都知道，所谓的“莫名其妙”，其实肯定是事出有因。
最近，在我的知识星球上，有个网友贴出了这么一个问题：
https://t.zsxq.com/0cp8IJSgG。
大概意思是，在全新且唯一的账号下，只有一个 app 上架的情况下还是遭遇了 other 延迟。
而且最近我翻查了下国外开发者遭遇 Other 问题的情况，还是发现了不少可以重新总结的点，除了我们经常遇到的账号关联，产品查重等情形外，老外更多遇到的是别的一些情况。
基础文案：
We need additional time to evaluate your submission and Apple Developer Program account. Your submission status will appear as “Rejected” in App Store Connect while we investigate. However, we do not require a revised binary or additional information from you at this time.
大家都知道账号关联很容易被触发，这部分就不谈了，之前的文章都有说到，我会放在文末。
我和不少同行朋友沟通，也发现了类似问题（我的微信：xq2723866）。觉得有必要理一理这个话题。
不少“绝望”的帖子
如果你认为 Other 只是苹果对中国开发者的歧视，那也不见得，可以看看以下老外的帖子，类似这样的帖子还有很多很多，这是一个叫 SSPGames_1 的开发者的经历：
Im in this situation over 3 months, always got this message. In 8 months i managed to publish only 2 apps. Very frustrating for my company, because of this and i wont extend Apple Developer subscription next year. I tryed everything, submit and resumbit, contact support, publish only 1 by 1 app and no help, always message “other” that they need extra time to evaluate app that stays in status forever. Realy embarrassing from company like Apple. Other stores publish app reviews in max 48 hours. — SSPGames_1
翻译：
我在这种情况下已经 3 个月多了，总是收到这条消息。 在 8 个月内，我只发布了 2 个应用程序。 对于我的公司来说非常令人沮丧，所以我明年不会续订 Apple Developer 订阅了。 我尝试了所有方法，反复提交，联系技术支持，一个一个的发布应用程序也没什么帮助，最后总是收到“Other”拒审，他们总是需要额外的时间来评估这个应用程序。 苹果这样的公司真的很尴尬。 其他商店最多在 48 小时内发布应用评论。 — SSPGames_1
这个叫 SSPGames_1 的网友已经因为 Other 问题决定黯然退出 iOS 开发者队伍了，可见 Other 杀伤力有多大。
类似这样的帖子，国际网络上还有很多，更别说还有很多 Youtube Up 的诉苦。
代码审查工具
有一个帖子是这么写的：
Automatically detect Security Vulnerabilities and Security Hotspots during your code review. Write the most efficient code possible with SonarQube. Basic analysis is always free! - kakaiikaka
翻译：
在代码审查期间自动检测安全漏洞和安全热点。 使用 SonarQube 编写尽可能高效的代码。 基本分析永远免费！- kakaiikaka
意思是苹果机器扫描出了应用程序中存在不安全的代码，需要更多时间审查确认。
这个可能性是很大的，尤其在开发者调用了一些私有 API 的情况下，另一个可能就是机器误判。
这里还提了一个建议，就是用工具对代码质量进行审查，这个工具叫 SonarQube ，这是一款开源的代码质量管理系统，里面提供了代码扫描的功能。作者建议提交的代码用它扫描一遍来做一遍自查。
我认为如果是习惯了通过 cocoapods 下不少 github 代码库进行开发的程序员，可以考虑一下。因为不少第三方库，可能会包含苹果认为不安全的代码。
SonarQube 的官网在这里：
https://www.sonarsource.com/products/sonarqube/
私有 API 的调用是导火索
另一个帖子里，提到了在提交新版时引入了私有 API 立刻被 Other 的经历：
yeah, several years ago, we used private APIs to get Wi-Fi signal strength(via method swizzling), then suddenly, in one submission, we received one message that contains "we need additional time to evaluate your submission…
翻译：
是的，几年前，我们使用私有 API 来获取 Wi-Fi 信号强度（通过方法混合），然后突然，在一次提交中，我们收到一条消息，其中包含“我们需要更多时间来评估您的提交…
显然的，喜欢“作死”的不止我们……这位朋友用了一个私有 API 获取了 Wi-Fi 信号强度，然后立刻就遭遇了苹果的延迟审查。
除了以上典型的帖子之外，类似的情况还有很多。不难看出，苹果的机器审查现在是相当严厉的了，私有 API 的调用其实在很多开发者那里已经不是什么敏感的事情。尤其是在小公司里，程序员只管实现代码，不会考虑太多调用的方法是否是审核条例允许的问题。而外包公司更甚，因为大部分功能实现是直接拷贝黏贴的，只要网上有实现方案，就一股脑拷贝过来。至于能不能过审，那是后话了。而且即使账号被调查了，也不一定查到自己头上，反正“我也就是打工的”。
另一方面，大量的第三方库，也存在了大量 API 调用违规的安全隐患。这也是为什么我在对待第三方库这件事上特别审慎的原因。
小结
针对 敏感API 这个可能导致 Other 审查的问题，我总结了以下几个重点方案：
- 静态扫描工具，似乎是有帮助的。例如刚说到的 SonarQube 。感兴趣的网友可以试用以下，我是还没有尝试（主要我自己开发就特别小心，很难遇到这类问题）。
- 代码中类和方法的命名，还是要求要“讲究”，苹果代码审查的静态扫描带有一定的“名称歧视”，一定要小心别用一些有嫌疑的单词。
- 第三方库的选择要注意，如果引用了第三方库，可以留意下网络上有没有因为这些库导致的审核问题，并且最好用准备好的字符串列表做一次二进制全文扫描。
- 遭遇审查后只能耐心等待一周。一周后可以考虑去催促，具体要不要催促，取决于开发者自身的情况。