Consumable InApp for number of specific action?

Question

Simple questions, maybe a simple answer is possible... 🙂

As far as I understand consumable InApp products, a consumable gives you a kind of credit which is used for specific actions within the target app. So far so good - usually consumables are used for games (virtual money or credits within games).

We have created an app for the netatmo weather station (www.netatmo.com), which makes use of the public netatmo API to download station data from the netatmo server. We thought about limiting access to the functionality of the app by limiting the number of allowed data downloads. Additionally we display Forecast.io weather data within that app, and we want to limit access to that functionality, too, by limiting the number of allowed forecast downloads.

Question: would Apple allow a consumable InApp product for a scenario where the consumable gives a user a credit of, lets say, 500 data requests? We want to avoid a subscription as we think that our scenario better fits to a consumable InApp type...

Thanks in advance,

Stefan

In-App Purchase

473

Posted by

totalidea

Reply

Add a Comment

Answer 1

yes, it sounds quite reasonable. Now consider this; how much 'protection' do you want to prevent abuse.

Here are some abuse cases: (most are 'over protection' unless the IAP is very valuable. However #1 should be implemented.)

1) user deletes and reinstalls the app and gets an additional 100 free units. You can prevent this by writing somethng to the keychain - the keychain survives delete and reinstall

2) user creates a backup before running the app, runs the app and uses the 100 credits, restores the backup, repeat. This is a security flaw in the system but what user would go to this trouble.

3) user purchases the consumable and backs up the device. User uses the credits and then restores from the backup regaining the consumable. You can prevent this by creating a non-backed up file at first launch and then detecting when it is 'missing'. Or you can write something to CloudKit that doesn't get restored (see #4).

4) user scams the IAP system by pushing a bogus 'purchase' into updatedTransactions. You avoid this by verifying the receipt. But because it is a consumable you need to protect against duplicate transaction_ids along with the deletion and reinstallation of the app or a restore from backup. You can do that by writing transaction_ids to the keychain or to CloudKit (or to your own server).

Posted by

PBK

Add a Comment

Answer 2

With one caveat, yes - why not? The caveat is that all apps have to do something before the IAP is purchased and, I believe, after the IAP is used up.

Posted by

PBK

Add a Comment

Answer 3

Yes, I thought about offering 100 data refreshes for free with the install of the app, and if those 100 have been used, a consumable IAP would give the user another 500 or something... And if those 100 and 500 have been used, the app would switch to limited functionality... Does that sound like something Apple would accept for a consumbale IAP?

Posted by

totalidea

Add a Comment

Answer 4

yes, it sounds quite reasonable. Now consider this; how much 'protection' do you want to prevent abuse.

Here are some abuse cases: (most are 'over protection' unless the IAP is very valuable. However #1 should be implemented.)

1) user deletes and reinstalls the app and gets an additional 100 free units. You can prevent this by writing somethng to the keychain - the keychain survives delete and reinstall

2) user creates a backup before running the app, runs the app and uses the 100 credits, restores the backup, repeat. This is a security flaw in the system but what user would go to this trouble.

3) user purchases the consumable and backs up the device. User uses the credits and then restores from the backup regaining the consumable. You can prevent this by creating a non-backed up file at first launch and then detecting when it is 'missing'. Or you can write something to CloudKit that doesn't get restored (see #4).

4) user scams the IAP system by pushing a bogus 'purchase' into updatedTransactions. You avoid this by verifying the receipt. But because it is a consumable you need to protect against duplicate transaction_ids along with the deletion and reinstallation of the app or a restore from backup. You can do that by writing transaction_ids to the keychain or to CloudKit (or to your own server).

Posted by

PBK

Add a Comment

Answer 5

Perfect. Thanks very much for your very detailed reply. Much appreciated!

Best wishes!

Stefan

Posted by

totalidea

Add a Comment

Consumable InApp for number of specific action?

Accepted Reply

Replies