项目背景 #

我正在用SwiftUI、Firebase后端、RevenueCat、Apple内购开发iOS应用，计划搭建一套推荐系统：邀请好友后，好友可获得终身高级版50%折扣购买权限；好友成功购买后，邀请者也能享受同款50%折扣。

核心前提：所有高级权限均通过Apple IAP/RevenueCat授权，绝不通过自定义代码直接授予，本次仅聚焦推荐机制的App Store合规性。

两种实现方案 #

方案A：采用Apple原生优惠码 #

• 通过App Store Connect API生成Apple Offer Codes
• 后端管理存储已生成的优惠码
• 用户A邀请用户B
• 用户B获取50%折扣的Apple优惠码
• 用户B通过Apple官方兑换流程完成IAP购买
• RevenueCat webhook确认购买完成
• 后端为用户A解锁另一张50%折扣的Apple优惠码
• 用户A可兑换该优惠码

方案B：自定义推荐码+隐藏RevenueCat产品 #

• 后端生成自定义推荐码
• 用户A分享推荐码给用户B
• 用户B在应用内输入推荐码
• 后端验证推荐状态
• 应用为用户B展示包含折扣IAP产品的付费墙（该产品与普通高级版权限完全一致，仅价格不同）
• 用户B通过正常Apple IAP流程完成购买
• RevenueCat授予对应高级权限
• RevenueCat webhook触发后，后端为用户A解锁同款折扣产品的购买权限

核心合规性问题 #

问题1 #

方案B中，所有权限仍来自Apple IAP，仅通过推荐码解锁折扣产品的可见性，是否会被Apple判定违反IAP规则？

问题2 #

将同一高级功能拆分为两个独立IAP产品（如lifetime_premium和lifetime_premium_discounted），两者解锁完全相同的RevenueCat权限/高级功能，仅特定用户可通过推荐系统购买折扣版，这种做法是否合规？还是Apple要求此类推荐折扣必须严格通过Apple Offer Codes/官方促销优惠实现？

基于审核经验的见解 #

关于问题1 #

这种仅控制折扣产品可见性的做法，大概率不会触发违规。Apple的核心规则是：所有应用内的付费内容/功能必须通过Apple IAP完成交易，且不能绕开Apple的支付流程。只要折扣产品本身是在App Store Connect中合法创建的IAP项目，且用户购买完全走Apple官方支付，仅仅通过推荐码控制产品展示（本质是给特定用户开放购买入口），并没有违反核心规则。

需要注意：不能在应用内宣传或引导用户通过非Apple渠道获取折扣权限，所有折扣购买的入口必须在应用内且走IAP；同时要确保折扣产品的描述和权限与普通版一致，避免误导用户。

关于问题2 #

拆分两个IAP产品对应同一权限的做法，存在一定审核风险，但并非绝对违规。Apple允许开发者创建不同价格的IAP产品，但前提是这些产品需要有明确的区分理由——如果两个产品完全提供相同的功能，仅仅是价格不同且仅对特定用户开放，Apple可能会认为这是在规避其促销规则，要求改用Apple Offer Codes或官方促销方式。

从实际案例来看，不少开发者采用这种方式通过了审核，但也有部分被Apple驳回，要求统一使用官方优惠机制。如果选择这种方式，建议在App Store Connect的产品描述中明确标注折扣版是“推荐专属优惠”，同时确保整个流程中没有任何绕开Apple支付的操作。

相对而言，方案A（使用Apple原生Offer Codes）是完全合规的方案，因为它完全遵循Apple的官方促销机制，不会有审核风险。缺点是Offer Codes有数量限制（每个促销活动最多生成10万个），且管理流程相对繁琐，但胜在合规性有保障。

内容的提问来源于stack exchange，提问作者Alexandr Čížek