SKReceiptRefreshRequest results in password prompt

Hi,


I have a subscription app. When the user subscribes, I set a local flag in NSUserDefaults so my app remembers the subscription state, but I also need to make sure I refresh and check receipts in order to detect cancellations. To do this, I'm calling SKReceiptRefreshRequest, then decoding and examining the receipts. I do this whenever the app opens, but only if the flag in NSUserDefaults indicates that a subscription is active.


Some of my users report that the app asks them to type in their iTunes password every time it opens, which is annoying. This seems to happen even if the user is signed in to iTunes & App Store via the Settings app and has Touch ID enabled. I'm able to duplicate the problem using a debug build, although I'm not confident that the issue isn't related to it being a debug build. The worst part is that you can't cancel it. If you press Cancel, the password dialog just keeps reappearing until you either type the password or force-kill the app.


What's the story with SKReceiptRefreshRequest? Is it OK to call this without asking the user, as long as I know for sure that they subscribed in the past? Is there any way I can tell whether the password prompt will appear, and/or cause iOS to stop prompting for it if the user presses Cancel?


Do I even need to use SKReceiptRefreshRequest, or will iOS refresh the receipts periodically without it? My subscriptions are month to month, and I don't care if someone gets an extra day here and there because the receipts weren't up to date.


Thanks,

Frank

Replies

Does verifying a receipt (via "https://buy.itunes.apple.com/verifyReceipt" or the sandbox equivalent) actually return a refreshed/up-to-date version of the receipt if one exists? I read something in the documentation which suggests this might be true. If it is, that would suggest that there is no need for me to use SKReceiptRefreshRequest as long as some version of the receipt exists locally.


Frank

The user has to log in before they can do a receipt refresh. That prevents user 1 from loading an autorenewable subscription in user 2's device and walking away - forever.


Your concern may be overly cautious since cancelled subscriptions are very rare.


You can now use an old receipt, send it to the Apple servers, and check the latest_receipt_info field to discover if the subscription was cancelled.