Can I create one in-app product for, say, some music, and then vary the exact track based on a database key?
So the user would buy a music product but the app keeps track of the exact data which comprises their instance?
As #Paulw11 said in his comment above, you can setup a consumable product ID that offers one or more "credits". Using the concept of credits is the only way you can dynamically allocate products to purchases without adding a product ID for each song in iTunes Connect.
Consumable products can be purchased multiple times, so allocate credit or direct the user to select the song once they buy the product. Be sure to call finishTransaction to "consume" the purchase, otherwise the transaction will remain in the queue and additional purchases will be blocked.
Be warned though, consumables are not restorable; if the user deletes and re-installs the app all their songs will be lost. One way to deal with this is to keep a server-side registry of songs a user has purchased, which means you will need user management and authentication etc.
Here's another stack question relates to yours.
Related
I am using In-app purchases in my app. After a user pays for a video, they can view it.
The problem is that I will have a huge list of videos on my server and price will vary for each video. So, every time when I post a video, do I need to add the video in iTunes Connect or is there an easier way?
A user can watch a video only a limited number of times (say 5 times) then the user needs to pay for the video again. How do I achieve this functionality? Use consumable and restore it after 5 times? Or, is there an approach for this?
Yes, you will have to create one product per consumable that you want to sell. After the user purchases the product, send the receipt to your backend and verify and store the purchase. Then notify your client and finish the transaction. You need to make sure you keep track of the consumables that your user purchased, this might be easier if you have a login system, otherwise, things get more complicated and you might need to create a restore and alias system with random user IDs. You can read more about how the system works here
Every time you start the app you would ask your server for the purchases that the specific user has made. That way you can programmatically figure out if the user can buy to watch the same video again and let it purchase another view.
It looks to me that what you are trying to achieve is not really scalable with the way the App Store IAPs are structured right now and I would really consider a subscription model rather than a consumable based app.
There's four types of In-App purchases and only Consumable fits your requirements.
You'd have to implement the logic to keep track of how many times a user can watch a given video and update this data whenever a user makes a purchase or watches a video. Ideally, you'd use a database (local or remote) to keep track of this data.
With this implementation, you would only need to register a new SKU when you want a new combination of price and number of views.
Here's an example of possible SKUs:
com.yourorganization.5dollars5views which lets a user view the selected video 5 times for $5
com.yourorganization.5dollars10views which lets a user view the selected video 10 times for $5
com.yourorganization.10dollars5views which lets a user view the selected video 5 times for $10
Application is about selling Audio books.
Option 1 : Consumable In App Purchase
It Will have different product ids with common price.
e.g. Audio A and Audio B both have price $2 then both Audio A and Audio B will share common product id.
All user purchase will be managed from server
Option 2 : Non Consumable In App Purchase
Will have different product ids for each audio.
I am confuse because there could be 10k + Audios. Can we create dynamic Non Consumable item ?
Any ideas how to make this scalable?
For that amount of dynamic content you will probably have to implement some kind of custom "currency" which would be a consumable item.
You can either make it completely arbitrary in amount, or you could try to make a few different IAP products to correspond with audio books in different price ranges. So something like $0.99$ book purchase, $1.99 book purchase, etc.
Apple allows up to 1000 in app purchase products to be created. So you cannot create 10k+ products. Also finding the product amongst this will be a very complex task for the user. See if you can bundle books of same price into a single bundle and price them economically so that users tend to purchase. 10 books for 10$ is better than 20$.
You should definitely go with non-consumable option since audio books do not deplete in time.
You have to maintain your own server in between the app and the Apple in app purchase and you need to have a user account management to track what books the user has purchased. You can create a different SKU For each price and and associate the product id with the book on your server and track the purchases done by the user on your own. Since multiple books could map to the same in-app product id, your app should handle the restoring purchases explicitly and based on your app user login enable the audio books on different devices.
Basically the in app flow would be used just for payment purposes. Enabling and downloading of the audio books will have to be controlled between your app and the server.
I would use something like a 2-Dimensional int array. [x][y] whereas x is your individual product ID, and y is the count on how many items are sold. You can then always link your x to a certain price. This way you can easily keep track on how many audio files 'y' with product ID 'x' got bought.
Never give two different audio files with maybe equivalent price the same ID. An ID should always be unique since there are a lot of problems that might occur later:
Implementing the audio files in a seperate database
Audio file becomes cheaper/more expensive, then you´d have to use another ID anyway
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
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.
I have a game where user can buy consumable product (i.e.: energy). Now, i want to start a SALE where i would sell MORE energy for the same amount of money (and probably different amount of energy, depending on user stats). Do i need to create new product ids for every possible amount of energy i sell, or i can use the same product? Is there any rules against this practice?
PS: Technicly i don't care either way - all user's data are saved on server and app purchases processed server-side. It's just a matter of time for apple to approve new products and some flexibility is lost.
It seems that this is possible. Reading from Overview of In-App Purchase:
Although non-consumable products may be recovered using the built-in capabilities of Store Kit, non-renewing subscriptions must be restored by your server. You are responsible for recording information about non-renewing subscriptions and restoring them to users. Optionally, consumable products could also be tracked by your server. For example, if your consumable product is a service provided by your server, you may want the user to retrieve the results of that request on multiple devices.
So it seems you should be good as long as you save all info about purchase for future reference.