I'm using in-App purchases in my App on behave of getting some sounds from the App to the iPhone as a ringtone.
I've used 'Consumable' as the type for in-App purchase so that the user would be able to buy a ringtone and download it directly.
However this App got rejected by Apple because they want this function to be non-Consumable (so you would be able to retrieve this ringtone more than once). I only don't know how to set this up in my App because there are more than 200 possible ringtones. The actual buying is not the difficult part but as a criteria for in-App purchases you need to be able to restore previous transactions. As I'm only using one product identifier I think I would not be able to identify which ringtone has been purchases when restoring.
So my final questions:
1. How can I identify which item is bought (i.e. by using tags in the purchase)?
2. Am I able to use only 1 product identifier for this In-App purchase. Or do I need to make a productIdentifier for each and every ringtone?
You have to create a non-Consumable product for each ringtone, each one with a different identifier, if Apple is refusing your app I think you have no other choice.
Related
I am trying to implement in app purchase for an iOS application
Did some googling and read this thread : Maintaining records of iOS in-app-purchases
It seems the way to go indicated is to use keychain
My in app purchase type is - Non-Consumables
Am wondering what is the best strategy for :
1
If a user has made an in-app purchase and resets the phone / deletes the app and then again downloads the app - do not want the user to pay up again
2
if the user does an in app purchase on an iPhone and then does an update on the iPad - he should get the in app purchase content without paying again
As far as possible do not want to store anything on my server if at all possible and am sure storing something locally on the device is useless for resets / multiple devices
Thanks!
akila
Apple keeps a record of what the user has purchased.
You also must implement a in app purchase restore button for the user in case of the two situations you mentioned above.
The inapp purchase restore button asks the App Store if the user has purchased before and sends you authorization if the have.
I recommend you use a library like RMStore on github to deal with in app purchases, the only big manual thing you need to do is obfuscate the in app purchase status as it stores it in the NSDefaults.
If a user has made an in-app purchase and resets the phone / deletes the app and then again downloads the app.... you want to restore the transactions by keeping an Restore button . Once you click on the restore button you want to connect with the storekit for restore the transactions. Their you can get the list of products that user has already purchased . Check the list of productids if your productid is match then unlock the content. All the best
I have an application which is using a consumable in app purchase for the products. Now I want to add some more portions to the existing application which can be used only if the user is subscribed for that option. So is it possible to use both type of inapp purchases in a single application. And can anybody provide an idea about how I can achieve this.
So you want to hide some in apps unless they have purchased a special in app?
Can't you just check in your code if the first one has been bought? Then display the rest.
You just go to iTunes Connect, to your app, and then to manage in-app purchase section.
You can add any amount of purchases there. Then your new in-app will be reviewd by Apple and you would be able to update your app with new code for retrieving that new in-app.
I want to implement in-app purchases to my app. I will be using the built-in product model where the IAP will unlock features within the code. My questions are:
how do I track the a purchase on a device (as to unlock the feature)? NSUserDefaults? The guide vaguely states "application preferences". They are not referring the Info.plist, as this can't be written once on the device. I also (obviously) want the user to back this up.
how do I enable the feature across mutiple devices on the same iTunes account? Do they have to "purchase" the feature on the other devices, or is there another way?
Thanks and regards,
--John
1) NSUSerDefaults is a good solution
2) Use a non consumable product for that http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/APIOverview/OverviewoftheStoreKitAPI.html#//apple_ref/doc/uid/TP40008267-CH100-SW1
User have to re-buy the product in each device but pay just the first time. A pop up "you've already buy this item" appear and you receive the same receipt.
I want to revamp the purchase model on one of my iphone apps to use in app purchasing to unlock the full featured app instead of having two separate apps. Is there a way to do this so that anyone who has previously purchases the app can get the purchase for free automatically?
The strategy that I used is to create a NSUserDefaults for previous purchasers of the application. Then I put that version in the app store for a month. I picked a month so that hopefully that all users had a chance to up date the app. After a month I put the in app purchase feature into the app and put that in the app store.
When I test to if I should use any in app purchase content I also check to see if the NSUserDetaults I created in the previous version is set.
There is not currently any way for the user to be given the In-App Purchase item for free.
However, if you can detect that the user upgraded from the old version (e.g. by examining NSUserDefaults) you can easily enough have your "did they purchase the full version?" check return true for that case too.
Can in-app purchase be available from different apps? I want to enable in-app purchase on a few different apps where the same non-consumable product catalog is available in all of the apps.
I assume I can create separate product ids for each app, but this will lead to duplicate data entry and make stats tracking more complicated.
No way for that, since each in-app purchase dependend on application for which it was created.