Probably a newbie question, I am using the Verify Store Receipts API to verify purchases of consumable items. How can I mark these items consumed so that the same receipt cannot be used again? Is there any option other than storing the used receipts?
Perhaps you could use a backend service to track receipts. Parse has brilliantly simple SDKs for iOS and Android that make it easy to persist bits of data to a provided server.
You could use iCloud (or normal UserDefaults) for that. However, you will probably prefer using your own servers.
Related
The answer to this question may be iCloud storage, but I am using this for a very light-weight piece of data and think it may be extreme to use iCloud for this one purpose. We have an in-app subscription app. Before we provided the app for free but would not deliver any content to it until the user subscribed to content through the in-app subscription.
Some reviews indicate people think that we are trying to trick them by saying free and then saying they have to subscribe. We want the app to be listed as the price of the subscription to avoid this misunderstanding but after the first year has elapsed offer them the in-app subscription to continue. We plan to store the initial launch date in persistent storage so that we can determine when to begin requiring a subscription receipt.
1) We wanted to use the keychain storage since this information will persist even if a user removes the app from his/her device and then re-installs. The problem is if the user gets a new device and does not restore it from an encrypted backup, then the initialized value will be lost.
2) If we use our servers to store this value for them, then there seems to be no way to tie it to that appleID; so that is ruled out as a possibility.
3) Back to iCloud, it just seems like a lot to add iCloud support just for this, and I believe the user still has to have iCloud enabled for this to work.
Does anyone know the solution to this data persistence problem? Help is appreciated!
Yes, nsubiquitouskeyvaluestore is the way to get it synched with new devices. Using this in conjunction with both keychain for storing on a device after app as been removed and nsuserdefaults for quick and easy unconstrained access is the way to go. Apple also has a way to read receipts for the actual app purchase now, but it only works for iOS 7. Solutions should conditionally rely on receipt data from nsbundle.mainbundle url if it is available.
I'm facing this problem while designing my iOS app. Suppose that a user purchases an app and downloads it to the iPhone. I would like to provide him with a default consumable item the first time he runs the app to use whenever he wants , however I would also like to track if the user has already consumed the item. This way if he decides to reinstall the app we can restore the transactions (if he used the item) or we can avoid possible intents to download different kind of content by reinstalling app and consuming default items each time. (Guess NSUserDefaults is not an option here).
One approach that came to my mind was using UDID(or any iOS 6 alternatives) to keep a record on server of the user's device the moment he uses the default item. But this will limit items just to the device from which they consumed content.
It would be great to support all the user's devices (like inAppPurchases), but I can't figure out a way to implement this.
Any suggestions or help would be great.
Thanks a lot.
In order to tie information to a user (not just a device she used at one time), you'll need to ask the user to identify herself and save it someplace other than the device. In other words, a backend that implements registration and login.
From scratch, this can be a lot of effort that an iOS developer didn't count on. Fortunately, there are several services in the world that provide a substantial head start. Here's a nice round-up. I've had direct experience only with Parse.com, and think it's excellent.
It is possible to store some application files and share it with another application?
Can application A remove files created in such shared space by application B?
In general, no. There are a few things you can consider.
All apps can read/write/share photos via the user's photos library.
Some apps have been known to share data via the address book. That is, they put data in a special address card which can be read by multiple apps.
If the apps have matching App ID bundle seeds, they can access the same keychain entries. I'm not sure how much data can be stored in the keychain, but it is possible to share data this way.
Apps can pass data to each other via a launch URL. That is, one app can ask iOS to open a URL that launches the next app, and that URL can have parameters that pass data.
No, each application has its own sandbox. Only way to communicate is to use custom URLs to call the other application or have a 'middle man' (eg a computer).
As an alternative to RupertP's answer, the only real work-around is to use a globally-accessible server. A lot of iOS devs use MobileMe's iDisk (not free) or DropBox (free for a limited account).
I would like to implement a application which backs up all the internal data like SMS, MMS, videos, audios, documents, call history stored in iPhone. But this seems to be not possible with API docs that the apple has released so far ... I have gone through the PDF of Enterprise distribution program and some of the links related to Enterprise Distribution Program, specifies about the Remote wipe and accessing of internal data like Calendar, SMS, MMS etc .... But they didn't mention how to do it programmatically.
Does Apple provide any special privileges like extra API support to access the internal data in their Enterprise Distribution Program?.
Is there any difference between Enterprise Distribution Program and Standard Distribution Program in the development point of view?
And since in-house distribution does not require Apple approval, shall we use some other method which are not officially mentioned in apple docs, to access the internal stored data ..
If so can anyone point out the way to do it?
Any help would be greatly appreciated
awaiting for your response
Best regards,
Mohammed Sadiq ....
You will not get any "bonus api", as there is no api, there's just public one, and private calls. Still, as you will distribute the app on in-house basis, you can use sqlite to get access to sms, calendar, phonebook data. I can't say for sure about other fields, as I don't know the exact permissions of the latest sandbox profile. You definitely can get access to everything on jailbroken device, but that might be not the best solution for you.
Standard and Enterprise are different in that Apple doesn't regulate the apps, as you said, I don't think there are any differences in development (except for what The company needs like internal server access) but there is the difference in distribution. You can't officially get that data programmatically but using undocumented calls sounds like it could work.
I need to implement trail period in my app. How to do it? Store day count in NSDefault? or some other?
You could store a counter in the preferences as you mention, although that counter would disappear if the user reset their phone.
However, I think it's all slightly besides the point. In general, Apple frowns upon apps that have this kind of functionality, so don't be surprised if your app gets rejected. Consider launching two different versions of your app instead, a "Lite" app and a "Full" app. The Lite app should have a reduced feature set, but it should never stop working.
Apple is against the idea of you disabling features to prompt people to pay money for something. Your app needs to be fully functional and a 'lite' version and a paid version seems to be how things work at the moment.
That being said - if you implemented it properly you could add in app purchase items to enhance your app. Your original 'lite' app could be $0 and additional features can be added for a fee.
The most bullet-proof method would be to send and maintain a copy of the iPhone's UUID in a database.
Then if the App is not "unlocked" it requires a "key" form the database every time it launches. You can then implement the trial period on the server side.
However, if you decide to use some type of encryption to store or transmit keys etc you will need a licence to distribute the App.
You make a light version of your app. There is no official way to have a trial version at this time. Hopefully Apple will eventually address the need, but I can't say I would hold my breath...