Opinions on tracking IAP subscription expiry dates

I’m finalising quite a simple app that carries out calculations and projections of sales volume.
I plan to allow ‘unlimited use’ of the app for £0.99 a month.
The free version will allow a user to carry out 3 calculations per day.

I am using CloudKit to allow users to sync their subscription between devices. I currently have everything up and running but I’m looking for opinions on how ‘sensible’ I should be. I don’t think it’s practical to check iCloud each time a user wants to carry out a quick calculation. Likewise I think it would be naive to purely store the expiry in user defaults. There would be nothing stopping a whole sales team using one account, getting the expiry stored to user defaults and then use the app unlimited for the whole month.

In the ideal scenario the ubiquityToken will match the one I store every time a ‘full’ check is done through iCloud. That way I know the expiry I store belongs to the user. I know it’s rare that people log out of iCloud but I found while testing that the ubiquityToken returned nil if the user didn’t enable iCloud documents (which I never had) so this ‘ideal’ match may not happen.

What are people’s opinions? Should a do a ‘full’ check each time? Every 3-4 hrs, every day or every few days? If I check too often I risk limiting paying customers if, like me, they use an iPad with no cellular connectivity when they’re out of the house without wifi. If I check too infrequently I risk my business model being abused and losing out on revenue. This is the first in a series of apps that I’m planning and I want to get a good handle on how to manage the expiry issue.

Sorry for the long post. It was difficult to explain what I meant.

Thanks
Steve

I think erring on the side of user convenience is the best policy. There’s a chance you may lose one or two sales but make your iCloud checks as infrequent as possible. You should have some idea of expected sales and have a way to decide whether the scheme you choose is or is not working (calculations reported vs. sales recorded perhaps) and if that shows your scheme isn’t working then tighten it up. You can probably convert people into paid customers if they get used to using your app and have had a few extra calculations for free but you probably can’t get them back if they angrily move on because your purchase validation recorded a false negative.

Thanks for the response. I got criticised on StackOverflow for asking an ‘opinion’ based question.

That is indeed the approach I’m taking. I’ve using a date stored in NSUserDefaults when the app launches so the response is instant. I then double check on iCloud once in a while to make sure the logged in user is who they say they are and the stored date isn’t from someone else who’s logged in.

This app is relatively cheap per month but I have larger apps with more functionality coming out so wanted to use this as a tester.

I like opinions, especially mine :slight_smile:

I guess that’s a difference, we’re all about tutorials and being a community of developers learning together. Sometimes there isn’t a hard answer that is always right. The SO philosophy is very “provably right or wrong”, and there’s a place for both.