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
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 have used consumable virtual currency purchases in my game.
The user can use that currency to unlock different types of jetpacks.
Apple rejected the game saying it requires a restore purchase button.
But apple's documentation says that consumable products does not require restore.
Why is apple considering the unlocked jetpacks as non-consumable products?
Following is the message that i have received in iTunes connect.
From Apple
10.6 - Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are
worth it. Apple sets a high bar. If your user interface is complex or
less than very good, it may be rejected
10.6 Details Your app uses intermediary currency to purchase items that function as non-consumable products but does not include a
restore mechanism. Users restore transactions to maintain access to
content that they’ve already purchased. Next Steps Please modify
your app to include an optional user registration feature that allows
users to restore their purchases to all of their iOS devices. We
recommend indicating that account registration is necessary to restore
previously purchased In-App Purchase products, and providing a way for
users to register later if they wish to access this content in the
future.
Should i make a restore mechanism for the jetpacks ?
I am using Soomla and unity3d for iap.
In summary, what Apple are saying is that you must include some kind of user registration / account feature where you are storing the users items on your server.
When they sign in on a new device, they should still have everything they have bought in your game.
It seems that Apple considers these purchases as non-consumable products because they are non-consumable products, no matter how you try to handle them in your app. If you define them as consumables, that means a customer loses them when they uninstall and reinstall the app, buy a new phone and restore their old phone to the new one, use the app on several phones, and so on. In other words, Apple considers your use of a consumable purchase to be cheating.
Your customers would feel exactly the same. If your marketing people try to maximise the flow of money from customers to your company, they should consider methods that Apple and your customers don't consider to be cheating.
not sure if this pass as a Stackoverflow question (close if not).
The problem we're facing at the moment is we have an app that we want to allow user to pay to unlock additional content space so they can create more content but be able to purchase multiple copies of that item without being charged twice unless they've exceeded what they've initially purchased.
So a concrete example is this:
Think of a item bag in World of Warcraft that lets user carry more items. (Our app isn't a game but it's the same concept). Users can buy many copies of the bag and at the same time, it doesn't matter if the user log into the app from their home computer or another computer, the bags are still tied to their account.
I'm aware that I have two options really:
Non-Cosumable In App Purchase
User buys the in app purchase item once but does not buy another copy. In other words, they can only ever have 1 copy of that item, not 10 or 20 copies (which our business logic requires in this case).
Consumable In App Purchase
Allows purchasing multiple copies of the item BUT they are non-transferable purchases. This would mean users would need to pay for the same item again even if they bought a new iPad, they can't transfer those "bags" to the new iPad or if they delete the app and reinstall the app, they would still need to pay for those items again.
Subscription based in app purchase doesn't exactly fit our model.
So is there a special type of non-consumable in app purchase but allows the user to buy multiple copies of that item/feature?
Additional Considerations
We do not have a third party server to track users and the number of copies of that item/feature they unlocked.
It also doesn't make sense to make a hundred copies of the in app purchase in iTunes Connect manually.
I think only making a consumable in app purchase is our only option. We're reluctant to force to user to have to pay for unlocking the same content twice but at the same time don't want users to be able to keep creating additional "bags" for free.
If user purchases a non-consumable purchase twice, I am sure Apple store has mechanism to prevent the purchase.
Instead, it would simply say: You have already purchased this product. It will be downloaded again. You will get all the delegates being called normally, and content delivery will happen as per what you have coded, but the customer will not be charged.
To avoid the payment flow, you can store the purchased item under itunes user's keychain, too.
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 social network with an iOS app and a website. For the purposes of illustration let's say I'm Facebook and I want to sell the ability to post on your friend's wall.
You would purchase this item once and forever be able to post on that friend's wall as much as you want, it does not expire.
You could purchase this item many times, but only once per friend.
If you purchase this ability on the iPhone app, you would also have this ability on the web app.
How do I do this using iOS in app purchases?
It's not a subscription because it does not expire or renew.
It's not a consumable item, because you do not use it up, it would be synched across devices, and it would be restored if you re-installed the app.
It's not a non-consumable product because you can purchase it multiple times (i.e. for multiple friendships).
How do I do this?
This doesn't appear to be possible within the bounds of Apple's in-app purchase system. If it were consumable, you wouldn't be able to restore it. And you have you manually create new in-app purchases, which then get approved by Apple, to add them, so you would have to manually create a non-consumable in-app purchase for every single user. That just isn't feasible. So I think you have to find some other way to approach this problem.
You could have a consumable purchase that adds the ability to post to an additional wall, where depending on where you buy it within the app, it'll apply to the particular wall being viewed. You can sync that with your server to see what walls that user is allowed to post on, and when the user signs in on other devices they will have access to those same walls there as well, so there is no "restoring" of purchases required, especially since you can't restore consumable purchases anyway. Now I don't know if Apple would like this approach because of how the in-app purchase would essentially be doing something different (allowing access to different walls) depending on which wall you're viewing, but it's the only way I can see it working within Apple's current setup for in-app purchases.