iOS 没有应用内购买机制的试用应用
iOS Trial App Without In-App Purchase Mechanism
我正在为客户开发一个应用程序，他希望该应用程序能够让用户注册并试用该应用程序 14 天，之后他们必须进行购买才能继续使用该应用程序.
我的客户不想吸收 Apple 因使用 Apple 的应用内购买机制而抽成的 30%。最初我建议实施第 3 方支付网关，但似乎 Apple 不允许通过第 3 方支付网关解锁应用程序功能的应用程序。
我的问题是：如果我们提交允许用户注册和登录的应用程序，但仅使用该应用程序 14 天且应用程序中没有任何形式的支付机制以允许用户继续使用该应用程序, app会被拒吗？正如我所想的那样，只在网站上安装支付网关，并在用户注册期间，向用户发送一封电子邮件，通知他们可以访问该网站进行支付。
我知道 Apple 拒绝 trial/demo 应用程序，但这在技术上是一个成熟的应用程序，通过该网站购买的用户将能够登录并执行全部功能。我也会给苹果提供一个功能齐全的测试账号。
谢谢！
我相信只要 14 天 "trial" 是该应用程序的全功能版本，这应该是完美的。
您的模型似乎与 Spotify 相似。在他们的网站上付费订阅，但使用应用程序中的服务。
这些资源可能会有所帮助：
http://www.quora.com/How-does-Apple-define-digital-content-when-taking-its-30-cut
简短回答：如果您允许注册并在试用期后阻止功能但不允许 IAP，Apple 将拒绝您。期间.
我对此有第一手了解，无耻插件 3..2..1..，简单 In/Out 提供 45 天免费试用，之后用户将被禁止使用该应用程序。在早期，我们通过小规模和使用永不过期的幸运试用账户逃脱了苹果的禁令。 Apple 会使用测试帐户进行审核，永远不会看到拒绝或阻止的警报和提示以在我们的网站上注册。在请求加速审查一天后，情况确实发生了变化。我们受到了更多的审查，他们拒绝了我们，因为我们基本上将用户引导到我们的网站进行订阅。
除杂志外，试用和订阅的 IAP 非常糟糕。它本质上是为杂志设计的，仅此而已。所以小心进入。我们最终做的是允许用户使用 IAP 在应用程序中订阅。我们的服务器管理谁订阅了谁没有订阅。它还管理他们拥有的订阅（IAP 或我们自己的）。您需要做很多奇怪的收据检查来管理来自 Apple 的订阅。如果用户想要更改为 bigger/lower 订阅计划，他们也会被卡住。这有点适合我们，因为唯一的方法是给我们发电子邮件，我们可以从 IAP (-30%) 转换为我们自己的 (-2.5% 用于卡处理)。
这个故事的寓意是，如果您计划允许用户在您的应用程序中创建帐户，那么您很可能有义务通过 IAP 提供订阅。如果您想避免 IAP，那么您还需要从您的应用和描述中删除对您网站的任何引用。如果您尝试引导他们绕过 IAP 流程，他们会在 meta 上破坏您。添加 IAP 后，我们就可以将每个人都指向我们的网站 "more information"，我们可以在其中将更多用户转换为我们自己的订阅而不是 IAP。目前，我们自己的订户数量与 Apple 的数量约为 75:1。因此，我们不会因从 Apple 获得的注册而损失太多。
我正在为客户开发一个应用程序，他希望该应用程序能够让用户注册并试用该应用程序 14 天，之后他们必须进行购买才能继续使用该应用程序.
我的客户不想吸收 Apple 因使用 Apple 的应用内购买机制而抽成的 30%。最初我建议实施第 3 方支付网关，但似乎 Apple 不允许通过第 3 方支付网关解锁应用程序功能的应用程序。
我的问题是：如果我们提交允许用户注册和登录的应用程序，但仅使用该应用程序 14 天且应用程序中没有任何形式的支付机制以允许用户继续使用该应用程序, app会被拒吗？正如我所想的那样，只在网站上安装支付网关，并在用户注册期间，向用户发送一封电子邮件，通知他们可以访问该网站进行支付。
我知道 Apple 拒绝 trial/demo 应用程序，但这在技术上是一个成熟的应用程序，通过该网站购买的用户将能够登录并执行全部功能。我也会给苹果提供一个功能齐全的测试账号。
谢谢！
我相信只要 14 天 "trial" 是该应用程序的全功能版本，这应该是完美的。
您的模型似乎与 Spotify 相似。在他们的网站上付费订阅，但使用应用程序中的服务。
这些资源可能会有所帮助：
http://www.quora.com/How-does-Apple-define-digital-content-when-taking-its-30-cut
简短回答：如果您允许注册并在试用期后阻止功能但不允许 IAP，Apple 将拒绝您。期间.
我对此有第一手了解，无耻插件 3..2..1..，简单 In/Out 提供 45 天免费试用，之后用户将被禁止使用该应用程序。在早期，我们通过小规模和使用永不过期的幸运试用账户逃脱了苹果的禁令。 Apple 会使用测试帐户进行审核，永远不会看到拒绝或阻止的警报和提示以在我们的网站上注册。在请求加速审查一天后，情况确实发生了变化。我们受到了更多的审查，他们拒绝了我们，因为我们基本上将用户引导到我们的网站进行订阅。
除杂志外，试用和订阅的 IAP 非常糟糕。它本质上是为杂志设计的，仅此而已。所以小心进入。我们最终做的是允许用户使用 IAP 在应用程序中订阅。我们的服务器管理谁订阅了谁没有订阅。它还管理他们拥有的订阅（IAP 或我们自己的）。您需要做很多奇怪的收据检查来管理来自 Apple 的订阅。如果用户想要更改为 bigger/lower 订阅计划，他们也会被卡住。这有点适合我们，因为唯一的方法是给我们发电子邮件，我们可以从 IAP (-30%) 转换为我们自己的 (-2.5% 用于卡处理)。
这个故事的寓意是，如果您计划允许用户在您的应用程序中创建帐户，那么您很可能有义务通过 IAP 提供订阅。如果您想避免 IAP，那么您还需要从您的应用和描述中删除对您网站的任何引用。如果您尝试引导他们绕过 IAP 流程，他们会在 meta 上破坏您。添加 IAP 后，我们就可以将每个人都指向我们的网站 "more information"，我们可以在其中将更多用户转换为我们自己的订阅而不是 IAP。目前，我们自己的订户数量与 Apple 的数量约为 75:1。因此，我们不会因从 Apple 获得的注册而损失太多。