The app I'm working on was recently rejected by Apple for containing an auto-renewable subscription. They recommended that we switch to non-renewing subscriptions for our content.
The one thing I can't quite wrap my brain round is how to restore a purchased subscription to a shared device. Apple recommends we don't use user login - something we would like to avoid ourselves. I did come across one solution where unique codes were used between the two devices - to validate a purchased subscription, through a server. But I believe that could be easily pirated, as in theory friends or employees within a company could share these unique codes with one another and avoid paying the subscription charge.
I can't really find much on Google about this, and was curious to know if anyone has been able to successfully implement a non-renewing subscription?
To paraphrase the advice we received from Apple when dealing with these issues:
Per the iTunes Connect Developer Guide:
...subscriptions must be provided on all devices associated with a
user. In App Purchase expects subscriptions to be delivered through an
external server that you will provide. You must provide infrastructure
to deliver subscriptions to multiple devices.
Apple consider user registration to be appropriate but won't allow you to make it obligatory. So registration must be optional and the user must be able to register at any time — including to allow them to share a subscription they've already bought between devices.
So it sounds like we may have received slightly different advice. Is it possible that Apple only told you not to require user login in general, separately from the requirement for distributing the subscription to all devices?
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
I'm changing one of my Mac apps from a paid model to a subscription model, by using auto-renewable subscriptions (IAP).
However, as the app is B2B, some users need to reimburse costs via their employer. While this is acceptable with payments only occurring once, with recurring payments this is simply annoying and sometimes even impossible.
Apple has a B2B Volume Purchase Program that supports companies to purchase a number of licenses and distribute this to their employees. However, IAPs (including auto-renewable subscriptions) are not supported.
I see this as a big limitation (especially knowing they take a 30% cut of sales) and the only way to solve this is to offer an additional mechanism to offer subscriptions next to IAPs, specifically for business needs.
My biggest concern is whether my app would be rejected because of this. I have been going through the (updated) guidelines and found some related items:
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.
This will be the case, but not exclusively because of the above mentioned limitation. I won't include a "Buy" link to the alternative method. However, I will include a text indicating that if a company wants to purchase multiple license for its employees, it can do this via our website (using a payment processor such as Stripe). Via this website codes will be made available that can be entered in the app to activate the license.
Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.
The app is distributed via the Mac App Store and it seems that they are more flexible here. However, it's a vague guideline and I'm not even sure if it's related to the problem I'm facing. What does it mean?
Hoping to read your opinions and experiences here. Thanks.
I have been emailing Apple about this but they have never replied. Also asked this question on the Apple Developer Forums but didn't got any help there too.
Decided to simply implement it and submit it to the App Store. They have accepted it without asking questions so apparently it is allowed. Important to mention is that I have not included the payment mechanism in the app. It asks for a license code that will be validated using my own service. This service also handles the payment via a web page.
Hope it helps others.
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
The IAP never expires. It is linked to a UUID in a KeyChain. The UUID is used in a database and other places as an identifer, and is critical to functionality.
If they upgrade to a newer iPhone and reuse the Apple ID, then the IAP follows them. The UUID shouldn't be changing in this case. Everything is cool so far.
But I don't want the IAP to be shared across multiple devices sharing the same Apple ID. I want them to pay for the IAP because every new device with the IAP represents a cost to me.
So I'm at a dilemma on how to classify it:
It isn't a consumable because you never need more than one and you don't use it up.
It could be a non-consumable, however, those need to be restored based on Apple ID. Here I get screwed with the Restore Purchases requirement. Basically, any Joe Schmoe can give out his Apple ID to his friends, and everybody gets the IAP for free. I don't want the IAP transferred to multiple devices.
It could be a non-renewing subscription, but it never expires, so they never need to add additional subscriptions. Can I specify the subscription lasts for a very long time (like 20 years) and limit them to purchasing one? The Apple guidelines aren't very specific on this.
It's not an auto-renewable subscription for multiple reasons detailed above.
It is a non-consumable. If you expect the Apple ID will be used across multiple devices, just price your IAP accordingly to account for this.
To be honest, I'm not sure this question is a great fit here because it's not a programming question and nobody but Apple's app review team will be able to give you a definite answer. I do know that subscriptions need to be restorable across multiple devices, so I don't know if that helps you out. The only non-restorable purchase type you can have is a consumable.
I am also not sure that your logic quite works - let's say you store the UUID in the keychain. How are you deriving it so that it's locked to the SIM? You don't have access to the IMEI or anything that uniquely identifies the SIM card on iOS.
You want to restrict the use to one device. That means it must be a "consumable IAP" according to Apple guidelines (note - non-renewing subscriptions won't work - they need to be copied to all devices owned by the user). So make it consumable but make it easy - sell the product as "5000 uses". Each time the user uses the function or the App, charge them one 'use'. This also has the advantage that a heavy user may willingly pay you twice.
And…you can use bluetooth (MKSession) or iCloud to transfer all remaining uses from one device to another device to solve the problem of a user purchasing a new device.
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?).