佟桐
最近团队遇到一个小问题，虽然最后很快解决了，但挺有代表性。我是做软件开发出身，早年一直写 iOS，现在基本不写代码了，更多是管项目、把控交付、帮团队解决问题。前几天，团队里的 iOS 工程师找到我，说 App 已经审核通过了，但是订阅一直审核不过，已经被 Apple 打回来了好几次。我看了审核原因，核心是：Guideline 2.1(b) - Performance - App Completeness里面写着：We have returned the In-App Purchase products as the required binary was not submitted.意思很直接：你提交了内购产品，但这次审核的 App 二进制没有和它们一起提交。这不是代码问题，而是提审流程问题。我先问他：“你在 App Store Connect 提交版本时，有没有把订阅产品一起勾上？”他说：“没有，而且我也没看到可以勾选的地方。”我基本就明白了。Apple 的规则是：In-App Purchase 必须和某个 App 版本关联提交，Apple 才会一起审核。 如果只是把订阅配置好了，却没跟某次版本提审一起送上去，Apple 就会认为这次二进制里没有这些内购，于是直接退回。很多人第一次遇到这种情况，都会怀疑是代码、支付接口或 StoreKit 配置有问题，其实往往不是。我继续确认了三件事：订阅产品是否已经配置完成。产品状态是否是 Ready to Submit。这次 App 版本是否已经把订阅一起关联提交。结果是：前两项没问题，第三项没做对。而且 App 当时已经审核通过，这个版本的提审流程其实已经结束了。继续在旧版本上折腾没有意义。正确做法只有一个：重新打一个 Build，版本号加一，在新版本里把订阅产品一起关联提交，再重新送审。他按这个流程重新操作：打新 Build创建新版本将订阅产品和新版本一起提交审核结果这次一次通过。整个过程没有改业务代码，也没有改支付逻辑，只是把审核流程走对了。这件事提醒我，Apple 的很多拒审并不一定是技术问题，而是流程问题。我现在已经很少亲自写 iOS 代码了，但以前踩过的坑，在这种时候反而最有价值。最后我跟工程师说：以后看到 Apple 拒审，先看清原因，再决定要不要改代码。很多时候，问题根本不在代码。
发布于 天津
分享
评论
1
未登录
友善发言
评论
加载中
