QuickBlox关于应用在App Store审核经验的分享

来自公司 QuickBlox 的开发者与 App2Top.ru 分享了他们一个应用的审核故事。简而言之，您将阅读到的文本关于两件事：遵守苹果规则的重要性以及坚持自己的利益的必要性。

本文的作者是 QuickBlox 的传播大使米哈伊尔·马尔琴科。

在移动应用开发中，常常会出现各种问题，这些问题往往与人为因素有关。在我们 QuickBlox 的创业公司中，冬季发生了这样的一个问题。

在我们为客户 AppsForGood 开发的项目 The Story Wall 上，截止日期是1月底。

但首先需要谈谈我们的客户和这个项目。AppsForGood 是一个大型慈善机构，帮助学校让孩子们了解现代技术。

The Story Wall 不是一款游戏，而是一个发展性应用，旨在帮助孩子们共同创造有趣的故事。这个应用是为了一个大型活动而制作的，该活动是为了展示六个英国学校儿童比赛获胜团队的应用。

客户为这个活动已经准备好了所有事宜，租用了场地，准备了设备，并邀请了嘉宾和记者。一切都很顺利，项目在截止日期前很久就完成了，没有任何问题。在演示的10天前，我们将游戏上传到 Apple App Store。

然而，负责开发该游戏的程序员注意到，由于我们的使用条款文本并不完全符合（模板没有针对特定应用和客户进行调整），应用可能会被拒绝。在过去的经验中，由于这种小问题公司没有拒绝过应用，所以我们决定不去关注这个小细节。

一周后，项目经理以放松的状态登录客户账户，想要享受“Ready for Sale”的标识，但却感到压力重重。构建状态为“Developer Rejected”。随后与程序员展开了对话：

— 你没有改动什么吗？

— 改动了，我取消了审核。

— 为什么？

— 嗯，那是因为没有使用条款文本。

团队开始恐慌。此时，使用条款文本已经准备好，但我们计划在首次版本发布后，再连同文本一起上传更新。没想到出乎意料，只得在一天内忙碌起来：制作透明背景的 HTML，合适大小的文本，然后将 HTML 再次提交审核。

与此同时，距离演示还有 4 个工作日——这是一种令人不快的情况。我们向客户解释了游戏审核延迟的原因，提到在新年之前 App Store 进行的维修会议。老实说，这样的解释只对刚入行的新手有效。但我们在这方面运气不错。

接下来只剩“最后一样事情”：在 4 个工作日内将构建推进到 App Store。显然，我们与 Apple Review Teams 完全没有联系。我们只能冒险并祈祷。经理每小时检查一次构建状态，经过一天，有人从审核团队对我们提出了 Metadata Rejected，并问了三个简单的问题：“这是什么应用？”“谁会使用它？”“是否有付费元素？”

所有这些问题在应用描述中都有答案。但经理还是给他们写了一个非常详细的回复，说明这是做什么用的，并强调游戏演示仅在三天后，就迫切需要审核通过，毕竟，孩子们在等待。

但那边并没有平静下来，几个小时后再次拒绝了应用，要求“给我们一个测试账户”。我们当然提供了，并再次提到，应用在商店中的出现直接关系到孩子们的情绪。在提交应用后已经过去了一天半的工作日。这是一个深夜，为确保审核员拥有所需的一切，团队决定先去休息。第二天早上，我们发现构建已经在 App Store 中显示为“Ready for Sale”——就在演示前一天。结果是，整个团队经历了两天的紧张，客户却很开心。

大家都挺过来了，因为我们在这种情况下没有抹黑自己的脸面，但我们明白，以后要更加注意这些细节。我们目前在其他项目上合作得很好。客户至今仍不知道自己是多么幸运，而我们，因为感到愧疚，并没有向他们解释。但过去的就过去了。

QuickBlox是一个 CaaS（Communication as a Service）服务，提供给移动应用的现成服务器基础设施。