I am adding consumable IAPs to my app, that allow the user to purchase credits to download data from a third-party database. I took this approach because I am charged per download by the data provider, so I pass the download cost on to the customer with a slight price markup. That way customers pay for each download and I am covered on my end. I briefly considered a subscription model, but decided it could be abused by heavy users and the higher entry cost might deter light users. With the consumable approach, download credits can start at just $0.99 for several thousand downloads. If a customer has multiple devices, they can just buy credits for each device as needed. They can buy more credits at any time. Seems like a good way to handle this.
Consumables are not restorable from Apple, but I plan to save a device's credits to the keychain so that they would be safe if the user deletes the app or moves to a new device (via backup). I was hoping to avoid depending on iCloud for this, since not all customers use iCloud.
One hitch in this approach is that if a user sets up a new device via backup, the download credits stay alive and usable on their old device. I know that a lot of people keep using their old devices, or hand them down to a family member, and many don't take the time to wipe the device or refresh the user account / Apple ID on the device. So it's possible that existing data download credits could be used from old and new devices, and I'd get billed for both device's downloads and could potentially lose money.
One possible solution -- though involving iCloud -- is to use the vendor-specific "identifierForVendor" to "allow" each device via iCloud key-value data. If my app launches and finds that the identifierForVendor value stored in the keychain is different from what it gets when creating a new one from scratch, it means the user is on a new device (or they deleted the app, but that won't matter). The app could then ask the user if they want to transfer credits to the new device, in which case a new identifierForVendor is created, stored in the keychain, and saved to iCloud as an allowed device. Meanwhile, the old identifierForVendor is marked as invalid on iCloud. So if someone else launches the app on the older device, the app will be able to determine the existing download credits are no longer valid (customer could purchase more and again mark that device's identifierForVendor as OK).
I think that would work, though it requires the user to have iCloud. Could also do this via a database on another server, but then we get into additional costs/hassles. So I am not sure if this is the best way to go. Any thoughts? Might be a whole lot of complexity to avoid cases where old devices are handed down or continue to be used by the customer.
Another option is to store credits in the keychain as non-transferrable data, so they would truly stay with the original device and not get carried to a new device via backup. That would enforce the typical behavior of a consumable being tied to a device and protect me from duplicate download billing, but it really limits the user, since they'd lose credits when going to a new device. This could be augmented with some sort of transfer, whereby credits are marked invalid on the old device and moved to the new device via iCloud, or AirDrop, or something, but the user needs to know to do this before disposing or wiping their old device.
Though I have offered other IAPs, this is my first foray into consumables, so I would like to know what other folks might be doing.
thanks,
219