13

When we need to refresh an iOS7 receipt, the appropriate way to do that is to use SKReceiptRefreshRequest. This brings up an Apple dialog for the user to sign in using their Apple ID. It also allows them to Cancel. How can we detect if the user presses Cancel? (Of course, in iOS6, this can be done using catching the cancel event for [[SKPaymentQueue defaultQueue] restoreCompletedTransactions]).

The SKReceiptRefreshRequest object has a delegate with two methods: 

- (void)requestDidFinish:(SKRequest *)request;
- (void)request:(SKRequest *)request didFailWithError:(NSError *)error;

In my code the requestDidFinish delegate method is called if the user does or does not press cancel.

The reason this is important to me is that I want to cancel the restore process if the user presses Cancel. If there was simply no receipt present after the refresh request, this might be relatively easy. However, sometimes there is a receipt (with some purchases) present in the app before the SKReceiptRefreshRequest, and so it stays in the app if the user cancels from the sign-in dialog.

I have two ideas for how to do this:

1) Delete the receipt from the bundle prior to the refresh request. The apparent problem with this is that the app can't remove files from the bundle (e.g., see Delete file from bundle after install). I tried. Nope.

2) Check the bytes of the receipt before the refresh request and after; if they differ, then this should indicate the user didn't press Cancel. If they don't differ, I'm not sure that does indicate they pressed Cancel. If the receipt contains purchases, I think that the bytes will differ because a refreshed receipt should have different transaction id's (but the same "original" transaction id's). If the receipt contains no purchases, I'm not sure about that.

Update, 11/9/15; I've just noticed that the delegate response to the user pressing Cancel appears to have changed. Now, didFailWithError is called. The problem of detecting user cancellation remains, however. How can we distinguish between the user pressing Cancel and a genuine error? I've been testing on iOS8.4 and iOS9.2 (beta). I have now reported this lack of distinguishability as a bug to Apple (bug #23476210).

Update, 11/10/15; This issue does not appear with iOS 9.0.2! I just tried this now with all three systems, with the same app binary, in the same approximate interval of time (within 20 minutes for all three systems): (A) iOS9.2 (13C5050d): Issue does occur (didFailWithError is called and can't distinguish between a real error and user pressing cancel), (B) iOS9.0.2, issue does not occur (requestDidFinish is called), and (C) iOS8.4.1, issue does occur. With all three system versions, this is running on real hardware, not the simulator.

Community
  • 1
  • 1
Chris Prince
  • 7,288
  • 2
  • 48
  • 66
  • I just tested number 2) above. And if there is a non-empty receipt prior to the refresh, that contains no purchases, it will be a **different** non-empty receipt after the refresh. Or at least in the two attempts I made that was the case. Of course, a more direct solution to this would be good. E.g.,, a delete method that was called to indicate the user pressed Cancel. Bytewise, 5515 bytes and 5522 bytes differed between the receipts in the tests I made. – Chris Prince Nov 21 '13 at 19:15

1 Answers1

2

iOS 9.2.1, Xcode 7.2.1, ARC enabled

I understand you asked this 2 years ago, but I recently had my run in with this issue and found a solution, and wanted to share here so others can save some time.

1) You may elect to store the receipt into keychain and access a copy of it, this allows you to delete it or refresh it as you see fit.

2) Yeah you can definitely check if it changed, I think the simplest way to do that is to use:

[receipt isEqualToData:(NSData *)(copyReceiptObject)]

My suggestion is as follows:

The key is to expect the error you get from the method:

- (void)request:(SKRequest *)request didFailWithError:(NSError *)error;

that gets called when the user taps cancel after the log in dialogue comes up to sign in to iTunes Store. There are many custom was you could do the refresh request, so the results may vary, but here is the different error you get for my request:

When there is no connection to iTunes:

Error Domain=SSErrorDomain Code=110 "Cannot connect to iTunes Store" UserInfo={NSLocalizedDescription=Cannot connect to iTunes Store, NSUnderlyingError=0x13c76d680 {Error Domain=NSURLErrorDomain Code=-1009 "Cannot connect to iTunes Store" UserInfo={NSLocalizedDescription=Cannot connect to iTunes Store, NSErrorFailingURLStringKey=

{ your product ids and corresponding URIs here }

, _kCFStreamErrorCodeKey=8, _kCFStreamErrorDomainKey=12, NSLocalizedDescription=The Internet connection appears to be offline.}}}

When the user taps cancel:

Error Domain=SSErrorDomain Code=16 "Cannot connect to iTunes Store" UserInfo={NSLocalizedDescription=Cannot connect to iTunes Store, NSUnderlyingError=0x13c6ac7b0 {Error Domain=AKAuthenticationError Code=-7003 "(null)"}}

The easiest I think is to check the error.code, if you want to get more complicated you may choose to parse the full error string to get more details about the error.

In my case, no connection error code is 110 and when the user cancels the log in the error code is 16. Handle the error.

serge-k
  • 3,394
  • 2
  • 24
  • 55
  • I want to know more about these error and asked a follow up question here http://stackoverflow.com/q/35851069/4018041 about SSErrorDomain. – serge-k Mar 07 '16 at 18:23
  • I've no idea how reliable it is to use error codes like this but as of January 2017 error code 16 is still being returned when cancel is pressed. – Richard Jan 24 '17 at 12:42
  • Not reliable at all, but I don't know any other way of detecting this and this is a desirable condition to detect to make the user experience better. Thanks for verifying that it still works. – serge-k Jan 27 '17 at 22:08