3

I have implemented consumable InApp Purchase in my iOS App. User will have to pay to see a content and it will expire in 24 hours.

Once user makes a payment, I will send a current date & expiration date to my server. Now, my server will return purchase date when I will fetch content list for particular logged in user. For example, If user Patrick logs into the App, he will able to see list of content. In that web service, I will also get the expiration date for that user and based on that time, I will show expiration time. If expiration time has passed, it will show BUY button in every content list cell.

The big concerned for my App is user changes his current date from device. If User periodically changes his/her current date and never gives his/her device chance to reach to the expiration date and s/he will get access to the content forever.

What is the best possible solution to overcome this situation ? This is the point where I have been stuck.

halfer
  • 19,824
  • 17
  • 99
  • 186
NSPratik
  • 4,714
  • 7
  • 51
  • 81

2 Answers2

4

If you can require the user to be online, then I would ignore the device time and do all of the verification with your server.

If you support offline access to the content, you'll need to live with the possibility that the user continuously sets their clock back and never uses your app while online. This seems like it would cripple their device's general functionality, so I wouldn't be overly concerned with it personally.

So either way, defer to your server time if you can possibly get it, otherwise just go with the device clock.

EDIT

More detail on the offline case:

  1. The only clock you have access to is the device clock.
  2. The user has control of their clock when they are not in your app.
  3. The user cannot selectively be offline for just your app, so by choosing to be offline they cannot use any of their device's online features.
  4. Likewise changing the clock is also a system-wide setting that would impact their reminders and their ability to tell time.

For all these reasons it makes sense to assume that a user would not reduce the functionality of their device just to get content for one app, and in my opinion it is not worth concerning yourself with. If it is critical to restrict content based on time, you should make connectivity a requirement.

Ben Flynn
  • 18,524
  • 20
  • 97
  • 142
3

Simply take note on the last time the app was launched (save it in GMT) and:

  • if the next time the user use your app the time (in GMT) is below your saved time make a warning (some nice thing about backward time travel not permitted)
  • on another backward time travel block the app until online connection is established and you can check all the content with server
  • time travel in forward is allowed (means user has actually understand that he is doing wrong and put time back to the right value), but not reset warning count

Remember to convert calendar from locale to gregorian representation (or whatever other representation you use/like).

Shebuka
  • 3,148
  • 1
  • 26
  • 43