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:
User creates an account aaa#foo.com
User pays for subscription on aaa#foo.com
User signs out and creates a second account zzz#foo.com
User presses "restore purchases"
Backend transfers the subscription from aaa#foo.com to zzz#foo.com.
User signs out of zzz#foo.com and back in to aaa#foo.com. 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.
Apple Review Guideline
Related
We are a website based service. We do not charge for accounts. We charge for services the user selects to do (such as exporting data). We collect money through our website and store that as credits in our system.
We have built a free app app and have been updating the app.
We would like to provide a user sign up in our app. We are having troubles figuring out if Apple will take issue with that. We understand if we sign up a new account in the app, Apple will take a 30% cut (ala Spotify).
The question is how do they handle free accounts?
EDIT:
Our app currently lets the user charge for services against their current credit balance (such as exporting a file) and have not had an issue with that in 4 years we have been doing it.
EDIT 2:
At one point, they did reject our App for hot linking to our website. That was 3 years ago and I forget if it was because they could create a new accout or could add credits to their account. I can't find a way to go back and look up the rejection notification.
Accounts are unrelated to purchases. Purchases and accounts are often used together, but this is a convenience and not strict requirement.
In your case:
The user may access the app with an account.
No payment is asked for the account.
Through this account, the user may receive content which has been paid for by credit card.
Credit card details have been submitted through your web site.
This is ok, as long as you do not take credit card payments in the app, or provide any buttons or links to credit card payments, from in the app.
According to the App Store Review guide.
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP. Any credits or
in-game currencies purchased via IAP must be consumed within the app
and may not expire, and you should make sure you have a restore
mechanism for any restorable in-app purchases. Please remember to
assign the correct purchasability type or your app will be rejected.
Apps should not directly or indirectly enable gifting of IAP content,
features, or consumable items to others. Apps distributed via the Mac
App Store may host plug-ins or extensions that are enabled with
mechanisms other than the App Store.
And
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically:
magazines, newspapers, books, audio, music, video, access to
professional databases, VoIP, cloud storage, and approved services
such as educational apps that manage student grades and schedules),
provided the app does not direct users to a purchasing mechanism other
than IAP.
In other words, users may access content that has been paid for outside of the app.
If the user is directed by the app to pay for something, then you may not use external payment services, and you must use In App Purchase.
So, hot linking to your web site from your app to accept payments is not allowed, whereas downloading content which has already been paid for through your web site outside of the app is allowed.
If in doubt, contact Apple directly through their support form, or the Apple developer program technical support.
We are developing one iOS application for iPhone which will free features as well app will have premium features with 4 in app purchase auto-renewable subscription options as below:
Single monthly subscription
Single yearly subscription
Family monthly subscription
Family yearly subscription
We will have one store screen inside the application which will have options to subscribe to various subscriptions which our app provides.
We found that user can go to device settings and manage their In-app purchase subscriptions.
We are also planning to provide options like user can upgrade from one subscription to other and user should also be able to down grade their subscription which would be all of the same options in reverse and back to the free version
Possible upgrading option:
Free to Any 4 subscription options
Single monthly to single yearly
Single monthly to family monthly
Single monthly to family yearly
Family monthly to family yearly
Possible down grading options:
Family yearly to family monthly
Family yearly to single monthly
Family monthly to single monthly
Single yearly to single monthly
From any 4 subscription options to Free version
Note:
According to Apple we can not use Apple family sharing option to share In App purchases so we are developing our own family sharing option in application. (Reference: https://support.apple.com/en-in/HT203046)
Queries:
We have some doubts how we can manage the subscription in our iOS application?
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
Apple will reject custom family sharing option using auto renewable subscription option?
What are the points we need to take care at our end which apple will not handle if we can go with above features?
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
It will be great help to us if any one can share their views or provide some guidance on which way we should go or if we are going off track from the apple policy.... all those kind of your feedback will help us to get things moving over here.
Thanks
We have some doubts how we can manage the subscription in our iOS application?
Because you are using your own user management system, you should persist the state of a subscription associated to the user in your database. When the user creates a purchase in the app, the app should send this receipt on to your API which will then proceed to validate it.
Once persisted, enqueue a scheduled process to run on the Subscription Expiration Date to update the record and ad infinitum until the expiration date is no longer in the future.
Your app should query your API when the user opens the app to determine their subscription status. Don't rely on the receipt locally in the app as your user's family member devices will not have this purchase associated.
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
If all products listed in iTunes Connect are of the same "Subscription Family", they will appear in the Subscription Management page in the users iTunes account.
When a user switches between products a transaction will be created and a SKPaymentTransactionStatePurchased event will be added to the SKPaymentQueue. This will be a new transaction with the same Original Transaction Identifier as the first purchase made with a product from the same Subscription Family with the Product Identifier reflecting the new product.
For this reason, you want to have your transaction observer in your app running in the background to receive any new transactions. When a new transaction is received you can either a) send the whole receipt to your API or b) inform your API that a new transaction has been received and re-validate the receipt that was persisted.
Going with (a) may become problematic as the receipts will become larger over time requiring more bandwidth from the user each time.
Going with (b) also has it's drawbacks because you can get into trouble with edge cases like the user switching iTunes accounts. A solution for this is to store the apps identifierForVendor with the receipt, and require the app to send the whole receipt if it does not match. Most of the time you will just be informing the API that a transaction has occurred, and on the few occasions that the identifier doesn't match it will send along a new receipt.
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
When restoring, a new transaction with a new transaction ID will be created, the original transaction ID will be the same though. If you create a transactions table in your database, you can ensure a transaction and it's original transaction is only ever associated to a single user, thus preventing users restoring purchases on other devices with a different user and gaining access to the subscription.
A restored transaction will be pushed onto the queue with SKPaymentTransactionStateRestored and so when this happens simply I advise sending the receipt to your API and process the receipt normally; associating any new transactions to the original user.
Apple will reject custom family sharing option using auto renewable subscription option?
I doubt it, but I am not Apple so don't take my word for gospel. Spotify have a similar scheme called "Spotify Family" where a user can share their Spotify account with their family, not sure if this is enabled for their iTunes app though.
What are the points we need to take care at our end which apple will not handle if we can go with above features?
You need your own API with user management and family association
Your users need to sign-in/register on your app
You will need to prevent family users from purchasing if their parent account already has a purchase.
Persist receipts and the identifierForVendor in the database.
Handle receipt validations using the validation API.
Persist a table of transactions and consider this table self-referential so that a transaction can belong to an original transaction through the original_transaction_id. Ensure the transaction_id column is unique.
Validate the receipt each time a transaction is due for renewal.
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
I see nothing in the guidelines except for section 17.2:
Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
I think this one is a little contradictory, since in 17.5 it states:
Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected
I guess by this, it means a user must be able to use the app without requiring registration, but I know of many examples of apps that do exactly this.
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
Case:
Our iOS app offers selling of custom made recipe packages that would be created for each user specifically. For example - user buys package of recipes, but for each user this package would be created individually, based on users preferences and needs, by someone from the app team. This package should be created in 5 days for example. If app team fails to create this package and deliver to end user in 5 days, automatic refund should be triggered and end user should receive money back that he spent on this in app purchase, thus invalidating purchased custom package.
Problem:
Is this kind of scenario even possible in Apple / iOS world? Can app developer trigger refund process of one specific purchase that end user made? If user isn't satisfied with specific purchase, could app developer trigger this is refund process if he has reference to transaction receipt?
P.S. We aren't really selling custom recipe packages, this was just an example scenario to help to understand this refund scenario case. ;)
EDIT:
If such scenario isn't possible via Apple refund, are there some examples of this kind of purchase model, implemented in some other way? It's hard to wrap my mind that only way for end user to get refund for something is to write Apple and that also needs to be done by user itself.
If you get paid using Apple services (in-app purchases) then NO, it isn't possible for an Apple Developer (business or individual) to refund App Store customers.
The only option is to direct customers to iTunes Store Customer Support as officially stated in the iTunes Connect screenshot below:
To increase the chances for your customers in getting refunded you could provide them with an e-mail stating that you would like them to receive a refund which they could show to the iTunes Support employee.
As a colleague stated, an option would be to use an external payment processor like PayPal which would allow you to manage refunds, but I think this will greatly increase the work needed since you will need to manage almost everything regarding payments on your own.
Also note that this option is highly restricted by Apple to only physical services or goods and sometimes Apple does not approve apps providing services through third-party payment processors. So.. you should be very careful what path you choose to take.
If the recipes you're providing to your customers are in digital format and users receive them in your app, you can be 100% sure that Apple will force you to use the in-app purchase system.
If such scenario isn't possible via Apple refund, are there some
examples of this kind of purchase model, implemented in some other
way?
In some cases you can use payment through PayPal (for example). We did it in our application where we had to take money of users and return it after a certain period. Check if you case is suitable for using third-party payment systems. Because (for example) Apple will restrict your app if you want to sell in-game content via Paypal, not with in-app purchase.
One very simple alternative would be to have your users buy virtual currency in your app that they can then spend on their recipe-package-orders. Since you are managing their virtual currency account balance, you can easily refund, give volume-discounts, etc. as you please. The only thing that will still be hard then is to have users return their virtual currency to get back their actual money.
There is no api for allowing users to refund a purchase (otherwise guess what can happen).
More info here
I am implementing an App with in app purchase of type:non-renewing subscriptions.
according to apple documents:
If your app uses non-renewing subscriptions, your app is responsible for the restoration process.
FROM HERE
My question is, if the restoring is mandatory by apple, how to prevent thousands of users sharing one apple account with only one description?
For example, if in my app, you pay $0.99 that can use this app for 10 days, from apple's requirements, the user must be able to use app within 10 days on any his/her devices, with simply enter the credentials. However, if the user set a simple account credentials and share it with 100 people, then, the 100 people don't have to buy the subscription anymore and can use the app free during the 10 days.
Some people keep assert that people won't share their account... how do you know that? i saw people register some apple id exclusive for sharing apps and games, and only need to pay once.
Besides, i don't implement my own server and my App don't need one. Is there a way to prevent this?
Thanks in advance
Since non-renewing subscriptions seem to require the app (developer) to use a separate (non-Apple) server to deal with the restore process (for example, see How to support multiple devices with non-renewing In-App Purchase?), why not have that server keep track of the number of restores per "user"? Then you could impose a maximum number of restores per "user". Each installed app that has made a purchase could have its own unique_token (for example, see app rejected.how to track user non-renewing subscription). The user would then have to have a username/password, which would be associated with the unique_token, in order to do a restore (for example, see Restore transactions for Non-renewing subscriptions without registration; and see Registration should be always optional on non-renewing subscription?).