I have a question regarding In App Purchases, If I have hundreds of videos in my application that are needed to be purchased like an auto-renewing subscriptions. For example, a user can buy a video for a duration of one month and then it would be renewed automatically.
But I don't want to create a separate in app purchase for all the videos, since the number of videos are liable to change dynamically. So I want a generic auto-renewing subscription for all of these in app purchases, but the problem here is if I make a generic auto-renewing subscription for all these videos and the user buy one of them then the user will have access to all the other videos which he did not buy.
Any ideas how to overcome this problem
I'm not sure how I would proceed in this case.
Using in-app purchase for unlocking a single video means you have a productId for that video OR for the unlocking of all the videos. In the latter case, it's something you don't want, as you said (seems reasonable). In the first case, you need to have a different productId for each one of the videos, unless you may not unlock more than one video at the same time. In this case, you could save the videoId somewhere in the cloud or on the device, so that you know which video you can and which video you can't watch.
If the scenario is instead: a user can unlock how many videos he wants, but for each video he has to buy a separate in-app purchase; then I'm not sure in-app purchases as they exist right now is the choice you may want.
Think about the case when a user wants to end an auto-renewing subscription. He will follow these instructions http://support.apple.com/kb/ht4098 and he should find one row for each of the videos he bought.
This means that on the Apple-side there has to be one productId for each one of the videos, so we're back again at the same point.
The only option I think is to implement your own purchasing system. Maybe if you explain your reasons to Apple during the review process, they won't reject the app. But it's quite risky I have to say.
Related
I am having a programmer code my iOS app, which he has done great. However, due to a new competitor we have decided to change from our current revenue model with In-App Purchases as subscription based to just having users pay a one-time fee. He tells me it'll take a lot of hours to make that change. Is it really true that there is no easy way around changing the code from having renewable purchases to simply have one-time purchases?
Well, this is a very objective question. It's impossible to tell you with any certainty without reviewing the actual code, but here are a few of the obstacles your developer may face:
The methods to buy a subscription is slightly different to buying a non-consumable product, however the app will need to continue to provide content users who are currently paying for a subscription. There is no way to change a subscription to a non-consumable product in iTunes Connect, and you may need to, or should ask and remind the user to cancel their subscription to prevent further renewals (you can't do this yourself or in the app, you can only link to the subscriptions page in their iTunes settings).
The app will need to check for either the subscription product (active or expired) or the non-consumable product has been purchased in order to provide the content. Support for this will need to be on the start of the app, purchase of a product and on the restore in-app purchases function.
There may be further complexities too, particularly if your app uses a backend API that syncs purchase information with a user account.
In conclusion, it's non-trivial, if your developer says it will take a lot of hours, I would be inclined to believe him.
I'm starting to see developers on IOS implement "if you buy a coin pack you'll also get all ads removed". From my understand of IOS in-app purchase I assume the coin pack as consumables, which would be $0.99, and ads removal as non-consumable, which I assume would be free, but how will I make the transaction? Will I make a payment request for the consumables and non-consumable together?
The simple answer is NO. While it might be possible to add two payments to payment queue in a row, it is important for user to understand that he is buying two products together. If you do addPayment twice, the entire flow will run twice, with alerts nagging the buyer - something that you don't want.
In such a case, you better make it so that consumable purchase unlocks the app so that ads do not appear. Single product - with description stating they got ad-removal as permanent bonus.
The ultimate difference between consumable and non-consumable is simply the fact that you can't restore consumables, so you must find a way to store that consumable somewhere, so your app knows to remove ads in case of device change / app deletion.
When you hear other devs offering similar, they are actually selling just one product at a time.
It is possible to sell >1 quantity of an IAP item, though.
I am implementing ios app in which I want to add In-App purchase (IAP).
I want to use in-app purchase for below situation:
1) User will make registration and pay $10.
2) Now, my app will allow user to download songs. (For ex. 10 songs of $1. So user can download 10 songs.)
3) User can add more credit by again making purchase of $10. (So if user wants to pay 2 times then he/she will get $20 in his/her account. And he can download 20 songs of $1.)
4) While downloading song, my app will check whether user has enough balance or not, then only he can download data. (If there is no balance then it will ask to make payment of $10 first.)
I have make research for above situation and also looked into in-app purchase guidelines from Apple.
From that, I come across below:
1) If I will use subscription: But in that case, user will be charged after some duration (for ex. monthly payment, 3 month payment). Which I don't want. Because I want user to pay only if he wants to download data and not have balance. So I think, subscription is not ideal.
2) If I will user Consumable in-app purchase: Here, I can use it, so user can pay as many times as he want. And I need to track his balance from server side. So, from server APIs, I can check user's balance. But I think, it may conflict with Apple rules.
"Consumable items are the one exception to the requirement that your content be available on all the user’s devices. Consumable items are digital items that are used up or disappear after use and can never be reused. Examples of consumable items include virtual poker chips, in-game ammunition, or virtual supplies such as construction materials."
So, user can make payment from his iPhone device. And he can download songs from his iPad device as well. Means, purchase is sharable.
But,
Consumables are device-by-device items, so their purchase needs to be made with the understanding that they are tied to the specific device. Apple does not let you restore a purchased consumable. You should warn your users that consumables are not shareable, and make it easy for users to purchase smaller blocks of items.
So can someone helps what kind of in-app purchase is suitable for above and also according to Apple Rules regarding in-app purchase.
Thanks in advance.
User "Non-Renewing Subscription" should fit your requirement https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/CreatingInAppPurchaseProducts.htm
My app got rejected because of restore button on non-renewing in app purchase. Do i have to remove restore button ? If i have to do so then how user will restore his purchases.Please help.
Non-renewing subscriptions are consumable. Therefore they cannot be restored. A restore button therefore makes no sense. You also need some kind of authentication/login system for the user. (See below for detailed explanations.)
Sources:
consumable vs. non-consumable in app purchases
non-renewing subscriptions
Update from WWDC2017: In Session #303 App Store Engineer Pete Hare explains at 3:00 that a non-renewing-subscription can be seen as "a consumable product with an expiry date on it"
There has been some debates in the comments wether non-renewing subscriptions are consumable or not, so I want to say something about it. "Consumable" means that you can consume them multiple times. Like "30 minutes of talking" in a voice-over-IP telephony application. On the other hand, there are non-consumables that you can buy only once. Like when you unlock all levels in a game app. You buy it once, and when you reset the device and redownload the app, you should be able to restore the purchase, so that you don't have to pay twice to unlock all levels. Furthermore, if you don't tap the restore-button in this case but just buy the "unlock all levels" package again, it works, but you will not be charged by apple a second time. That's why it is called non-consumable. It's some kind of metapher. An apple is "consumable". Once it is consumed, it is gone. A chair is non-consumable. You have it as long as you don't destroy it or give it away.
So, it makes sense to regard a non-renewing subscription as non-consumable. If you buy it a second time, you shouldn't pay twice, you should just use the old subscription you already have. If you reset the device, you should be able to restore the subscription once you re-download the app. The restoration is just not done by Apple but by the app itself.
I still regard non-renewing subscriptions as consumable though. I use a simple definition of consumable vs. non-consumable: An in-app-purchase is consumable, when, from the point of view of the StoreKit API, it can be purchased multiple times in the same week by the same user. All consumable IAP-items cannot be restored through the StoreKit. All non-consumable IAP-items can be restored through the StoreKit.
So, the developer is himself responsible for restoring the in-app-purchase of a non-renewing subscription, right? No, sorry. How would the app restore the in-app-purchase of a non-renewing subscription? Suppose I have an iPod and I subscribe to 1 month of listening to the Foo-radio. Now I want to also listen to the Foo-Radio on my iPad. Soo, I install the Foo-App on my iPad and tap the "restore" button. Well... what is the "restore" button supposed to do? How can it know if I already have purchased a "Foo"-subscription or not, and how long it will still be valid? Answer: it can not. This approach does not work.
In order for a non-renewing subscription to work, you have to login the user first, to tie the subscription to some online account. Username/Password, Open-ID, Login via Gmail, Facebook, etc. all would work. Then, when the user purchases an n-r subscription you have to store the fact that he subscribed on some server and link it to his account on the server. You also have to prevent the user from buying the n-r subscription when he is not already logged in. Let's continue with my iPod/iPad-example above. I download the app on my iPad, I login with Facebook, and voila, I can use the "Foo"-subscription now. There is no need for a "restore" button, because the app should check at login-time which subscriptions the user has.
There will be some additional problems to deal with. (1) For example, nothing prevents the user from logging in into 200 devices. Here the problem is not a user with 200 devices, but a university with 1000 students where 180 students share the same account. (2) If the server crashes, some people will probably lose their subscriptions. Problem (1) can potentially lead to decreased income. Problem (2) can lead to angry and unhappy customers.
From Apple: "Non-renewable subscriptions. Subscriptions that don’t involve delivering episodic content. Examples include access to a database of historic photos or a collection of flight maps. It’s your app’s responsibility to make the subscription available on all of the user’s devices and to let users restore the purchase. This product type is often used when your users already have an account on your server that you can use to identify them when restoring content. Expiration and the duration of the subscription are also left to your app (or your server) to implement and enforce." [Italics and bold added] https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
Apple Reviewer's current-similar response about Non-Renewing Subscriptions "Your app offers Non-Renewing Subscriptions and this purchasability type must have its own restoring function - if you have removed it please re-implement it. Furthermore, your app must also offer a function, such as account creation, such that purchases can be tracked across all of a user's devices. Please implement a login feature as well as a restore mechanism prior to resubmitting your revised binary for review."
I have a magazine app, and I want to provide users a one year auto-renewable subscription, and for non-subscribed users, they can use non-consumable IAPs to pay for each issue and then download it. What is the best way to implement it?
For auto-renewable subscription I don't think it's a problem. I can follow the tutorial at http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions/ to finish this part. But for the non-consumable IAP part, I'm not sure. Do I need to add all the non-consumable IAPs for future issues before I submit the app? If I do this, how could Apple review my IAPs, because the future issues are not prepared at the reviewing time. Or, can I add non-consumable IAPs after my app is published to the App store? For example, every time when a new issue is ready in our server, we add a new non-soncumable IAP in iTC, and also set the product id to the issue in the server. When the non-subscribed user click that issue, the purchase for the specified product id will start. Is it possible?
After some research I found that the best way to implement it is to set up a new non-consumable IAP at each time when you want to publish a new issue.
The only problem is that, each IAP needs to be submitted for review, and before it is approved, the users who try to buy the issue will get an error message: "Cannot connect to the iTunes store". I haven't figured out how to know that the IAP is in review, so I can popup a nicer message like "Issue is review, please wait" other than a confusing error message.
I have a magazine app, and I want to provide users a one year
auto-renewable subscription, and for non-subscribed users, they can
use non-consumable IAPs to pay for each issue and then download it.
What is the best way to implement it?
You should accept your solution, but here is another case, maybe it helps you or others:
The subscribers can have they magazines, which are not in at iTunes Server, but at your hosting. Those magazines not need to bypass the apple review.
It depends whether you want a user to be able to permanently have a record stored in their app receipt of the issues they have bought. You might want this, if you want a user to be able to delete the app, with all associated content, then later re-install the app, and be able to download the specific back issues they purchased previously—all without having any user account on your own server. The use of a non-consumable in-app purchase also enables you to give them access to these issues across multiple devices that are signed in to that Apple ID, again without having to run your own user account-server combination to track purchased issues.
If these features don't matter to you, then there is a solution you could consider that is much simpler where you don't have to keep creating new in-app purchase products. Have a consumable in-app purchase product that is called something like Purchase One Issue. When a person buys this product, they get one credit and they can use this to select the issue they wish to be given access to. Your app then gives them access to that issue. You could also of course reverse this process in the UX: they pick the issue, click buy, you send them into the purchase process for the Purchase One Issue product, and you automatically give them access to the selected issue since they already selected it.
Note: consumable in-app purchases are not stored in the app receipt, so a user couldn't use this approach to 'restore previous purchases'. In scenarios where this is acceptable however, this is a much less labour intensive approach once set up.