没有应用内购买机制的iOS试用应用
我正在为客户开发一个应用程序，他希望该应用程序能够让用户注册并试用14天，然后他们必须购买才能继续使用该应用程序.
I am developing an app for a client, where he wishes the app to be able to have users to sign up and try out the app for 14 days, after which they have to make a purchase to continue using the app.
我的客户不想使用Apple的应用程序内购买机制来吸收Apple的30％的折扣.最初，我建议实施第3方支付网关，但似乎Apple不允许通过第3方支付网关解锁应用功能的应用.
My client does not want to absorb Apple's 30% cut for using Apple's in-app purchase mechanism. Initially I suggested implementing a 3rd party payment gateway, but it seems that Apple does not allow app that unlocks app functionalities via a 3rd party payment gateway.
我的问题是:如果我们提交允许用户注册和登录的应用程序，但仅使用该应用程序14天，而该应用程序中没有任何形式的支付机制以允许用户继续使用该应用程序，该应用程序被拒绝?当我想到只在网站上安装支付网关时，并在用户注册期间向用户发送电子邮件，通知他们可以访问该网站进行支付.
My question is this: if we submit the app that allows users to sign up and login, but only use the app for 14 days without any form of payment mechanisms in the app to allow the user to continue using the app, will the app be rejected? As I was thinking to just have the payment gateway on a website, and during user sign-up, send the user an email informing them that they can go to the website to make a payment.
我知道Apple拒绝试用/演示应用程序，但是从技术上讲，这是一个完整的应用程序，通过网站购买的用户将能够登录并执行全部功能.我还将为Apple提供一个功能完备的测试帐户.
I know that Apple rejects trial/demo apps, but this is technically a full fledged app where users that purchased via the website will be able to login and perform full functionality. I will also provide Apple with a test account that is fully functional.
谢谢！
简短答案:如果您在试用期后允许没有IAP的情况下允许注册和阻止功能，Apple将拒绝您.期间.
Short answer: Apple will reject you if you allow signups and block functionality after a trial period without allowing IAP. Period.
我对此有第一手了解，无耻的插件3..2..1 ..，简单输入/输出提供了45天的免费试用期，此后用户被禁止使用该应用程序.早期，我们体积小巧，使用了永不过期的试用帐户，从而摆脱了苹果的禁令.Apple会使用测试帐户进行审查，不会在我们的网站上看到拒绝或阻止的警报和提示.在要求加急审查的一天后，情况确实发生了变化.我们受到了更多的审查，他们拒绝了我们，因为他们实际上是在引导用户访问我们的网站进行订阅.
I have first hand knowledge of this, shameless plug in 3..2..1.., Simple In/Out offers a 45 day free trial, after which users are blocked from using the app. In the early days, we escaped Apple's ban hammer by being small and using a blessed trial account that never expired. Apple would review using test account, never see rejection or blocked alerts and prompts to sign up on our website. That did change one day after requesting an expedited review. We got a lot more scrutiny and they rejected us for essentially steering users to our website for subscribing.
用于杂志和杂志以外的其他订阅和订阅的IAP非常糟糕.它本质上是为杂志设计的，仅此而已.因此请当心.我们最终要做的是允许用户使用IAP订阅应用程序.我们的服务器管理谁已订阅和谁未订阅.它还管理他们拥有哪些订阅(IAP或我们自己的订阅).您需要进行很多奇怪的收据检查，才能管理来自Apple的订阅.如果用户想要更改为更大/更低的订阅计划，也将陷入困境.哪种方法对我们有效，因为唯一的方法是给我们发送电子邮件，其中我们可以将IAP(-30％)转换为我们自己的(对于卡处理，则为-2.5％).
The IAP for trials and subscriptions other than magazines is pretty terrible. It is essentially designed for magazines, and that's it. So beware going in. What we eventually did was allow users to subscribe in the app using IAP. Our server manages who is subscribed and who isn't. It also manages which subscription they have (IAP or our own). There is a lot of weird receipt checks you need to do to manage the subscription from Apple. The user is also stuck if they want to change to a bigger/lower subscription plan. Which kinda works for us because the only way to do it is email us, in which we can convert from IAP (-30%) to our own (-2.5% for card processing).
这个故事的寓意是，如果您计划允许用户在您的应用程序内创建帐户，那么您很可能有义务通过IAP提供订阅.如果要避免使用IAP，则还需要从应用程序和描述中删除对网站的任何引用.如果您尝试引导他们围绕IAP流程进行操作，它们将使您破产.添加IAP后，我们便可以将每个人都指向我们的网站以获取更多信息"，在该网站中，我们可以将更多用户转换为我们自己的订阅而不是IAP.目前，我们与苹果的订户数量约为75:1.因此，我们不会因从Apple获得的注册而损失很多.
The moral of this story is that if you plan on allowing users to create accounts inside your app, then you will most likely be obligated to offer subscriptions via IAP. If you want to avoid IAP, then you will also need to strip any references to your website from your app and description. They will bust you on meta if you try and steer them around the IAP process. Once we added IAP, we were allowed to point everyone to our website for "more information" in which we are able to convert more users to our own subscription rather than IAP. Right now, our number of our own subscribers vs. Apple is about 75:1. So we don't lose much over the signups we get from Apple.