I'm currently building an iOS app which includes auto-renewing subscriptions via iTunes. I also provide a secondary subscription service via Stripe for web users, and a subscription on either platform enables premium features for all platforms.
A subscription is therefore tied to the user account in my backend database. I don't particularly care what device they are on.
One problem I am envisaging is that if a user creates a second account on my service, and presses restore purchase in the app, the subscription according to apple must be given. As far as I can tell, showing error such as "You're subscription is already active on another account" would not be allowed.
So I was wondering, instead of rejecting the subscription, can I instead transfer it? Something like this flow:
[email protected][email protected][email protected][email protected] to [email protected].[email protected] and back in to [email protected]. The first account is no longer "premium", as the second one has the subscription.Would this be an acceptable approach to take?
Well, in the Apple guideline is not clear enough to know if your option is good. But I think it would be a good option because like that you are allowing user to get their subscription on all of their device as if they use their good account
3.1.2(a) Permissible uses: If you offer an auto-renewing subscription, you must provide ongoing value to the customer, and the subscription period must last at least seven days and be available across all of the user’s devices. While the following list is not exhaustive, examples of appropriate subscriptions include: new game levels; episodic content; multi-player support; apps that offer consistent, substantive updates; access to large collections of, or continually updated, media content; software as a service (“SAAS”); and cloud support. In addition: Subscriptions may be offered alongside a la carte offerings (e.g. you may offer a subscription to an entire library of films as well the purchase or rental of a single movie). You may offer a single subscription that is shared across your own apps and services, but these subscriptions may not extend to third party apps or services. Games offered in a game subscription must be owned or exclusively licensed by the developer (e.g. not part of a game publishing platform). Each game must be downloaded directly from the App Store, must be designed to avoid duplicate payment by a subscriber, and should not disadvantage non-subscriber customers. Subscriptions must work on all of the user’s devices where the app is available. Learn more about sharing a subscription across your apps. Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app. As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc. Subscriptions may include consumable credits, gems, in-game currencies, etc., and you may offer subscriptions that include access to discounted consumable goods (e.g. a platinum membership that exposes gem-packs for a reduced price). If you are changing your existing app to a subscription-based business model, you should not take away the primary functionality existing users have already paid for. For example, let customers who have already purchased a “full game unlock” continue to access the full game after you introduce a subscription model for new customers.