Ionic 3 iOS应用内订阅恢复功能遭苹果拒审，求技术排查

一、苹果如何检测到混淆后的JS逻辑？ #

其实不用太惊讶，苹果审核团队有一套成熟的手段来识别混淆后的代码逻辑，尤其是针对IAP这种核心管控模块：

• 静态分析工具：即使JS代码被混淆，工具依然能追踪到关键API的调用链——比如你用到的restoreCompletedTransactions、purchase等IAP相关方法，它们的调用顺序、条件分支是可以被解析出来的。混淆只是改变了变量名和代码的可读性，核心的业务执行路径根本藏不住。
• 实际功能测试：审核人员会实际操作你的应用，模拟各种场景（比如从未订阅过的用户、已订阅但卸载重装的用户、恢复失败的情况），通过实际行为就能判断你的恢复机制逻辑是否有问题——比如是否强制自动恢复而没有给用户主动触发的选项，或者恢复后的状态判断逻辑不符合规范。
• 针对性监管优先级：IAP是苹果重点管控的模块，他们有专门的检测规则和流程，对这类代码的识别优先级极高，不会因为混淆就放过。

二、苹果要求重写恢复模块的可能原因 #

结合你描述的逻辑（尝试恢复→成功则判定订阅→否则引导订阅），大概率是踩了苹果的IAP规范红线：

• 恢复操作必须由用户主动触发：苹果明确不允许应用启动时自动执行恢复购买操作，恢复功能应该做成一个可让用户手动点击的选项（比如设置里的「恢复购买」按钮），而不是自动运行来判断订阅状态。自动恢复可能会被判定为干扰用户或者不符合隐私/规范要求。
• 缺失服务器端收据验证：即使恢复成功，你可能没有向苹果服务器验证收据的有效性，直接本地判定订阅状态——苹果要求所有订阅状态的判定必须以服务器端验证的结果为准，本地的恢复成功回调不能作为最终依据，防止恶意篡改。
• 错误处理不完整：比如恢复失败（用户没有已购买项目、网络问题等）时，你的逻辑是否正确引导，而不是直接跳转订阅，或者没有给用户清晰的错误提示。

三、修复建议（针对Ionic 3的IAP模块） #

如果要重写恢复模块，建议严格遵循苹果规范：

1. 添加手动恢复入口：在应用的设置页面或订阅页面，添加一个明确的「恢复购买」按钮，只有用户主动点击时才调用restoreCompletedTransactions。
2. 强制服务器端收据验证：恢复成功后，将获取到的收据发送到你的后端服务器，由后端调用苹果的验证API（正式环境https://buy.itunes.apple.com/verifyReceipt，沙箱环境https://sandbox.itunes.apple.com/verifyReceipt），根据返回结果判定用户的订阅状态。
3. 完善错误处理逻辑：处理恢复操作的各种错误情况，比如SKErrorPaymentCancelled、SKErrorPaymentInvalid等，给用户清晰的提示，而不是直接引导订阅。
4. 优化订阅状态判断流程：不要只依赖恢复操作，平时应该通过定期验证收据来更新订阅状态，恢复操作仅用于用户重装应用或更换设备时找回订阅。

内容的提问来源于stack exchange，提问作者Omer Shacham