Auto-renewing subscription and app receipt

Question

I want to know if and when the app receipt is automagically refreshed when an IAP auto-renew subscription auto renews. The documentation implies that the app receipt is updated when a purchase is made (renewal?) but I'm not seeing this behavior in the IAP sandbox:

Information about consumable products and non-renewing subscriptions is added to the receipt when they’re paid for and remains in the receipt until you finish the transaction. After you finish the transaction, this information is removed the next time the receipt is updated—for example, the next time the user makes a purchase.

Information about all other kinds of purchases is added to the receipt when they’re paid for and remains in the receipt indefinitely.

Furthermore, the docs state:

After a subscription is successfully renewed, Store Kit adds a transaction for the renewal to the transaction queue. Your app checks the transaction queue on launch and handles the renewal the same way as any other transaction. Note that if your app is already running when the subscription renews, the transaction observer is not called; your app finds out about the renewal the next time it’s launched.

To me this implies that I can monitor the SKPaymentQueue for completed transactions then check the app receipt to find record of them. But I'm not seeing this in practice in the IAP sandbox. In the IAP sandbox I have an auto-renew subscription which is auto-renewing (6 times per user/purchase, normal sandbox behavior) but to discover the renewal I need to manually refresh the app receipt.

Assuming this all does work the way I'm expecting it to, are there best practices for testing in the IAP sandbox to trigger this behavior?

Answer 1

As a side note, the documentation is inconsistent on the types of purchases and their persistence in the receipt -- see my answer to this question.

The receipt is updated on the server-side when the auto-renew ticks over -- you can confirm this by checking with a call to the server-side validateReceipt method.

UPDATE: Having seen that you're using RMStore, I mocked something up so that I could look at the behavior.

It looks to me like the client-side receipt is being updated. My scenario: one month AR subscription (so 5 minute renew in the sandbox). I put some diagnostic code in viewDidLoad:

RMAppReceipt *receipt = [RMAppReceipt bundleReceipt];
if (receipt != nil) {
    NSDateFormatter* localDateTime = [[NSDateFormatter alloc] init];
    [localDateTime setTimeZone:[NSTimeZone timeZoneWithName:@"PST"]];
    [localDateTime setDateFormat:@"yyyy.MM.dd HH:mm:ss zzz"];

    for (RMAppReceiptIAP* purchase in receipt.inAppPurchases) {
        NSString* cancellationDate = nil;
        if (purchase.cancellationDate) {
            cancellationDate = [localDateTime stringFromDate:purchase.cancellationDate];
        }
        NSLog(@"Transaction: %@: product %@, original purchase date: %@, expiration date: %@, cancellation date: %@",
              purchase.originalTransactionIdentifier,
              purchase.productIdentifier,
              [localDateTime stringFromDate:purchase.originalPurchaseDate],
              [localDateTime stringFromDate:purchase.subscriptionExpirationDate],
              cancellationDate);
    }

I also put a breakpoint in RMStore's paymentQueue:updatedTransactions: to see if the queue is updated with subsequent AR purchases.

I then purchased one month of my test product, verified the transaction and then quit the application.

On subsequent re-invocations of the application at 5 minute intervals, I then saw the breakpoint in the SKPaymentTransactionObserver method being hit with transactionSate SKPaymentTransactionStatePurchased. The log showed successive additions of the purchases (only last version shown):

2015-05-27 14:27:32.828 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:02:59 GMT-7, expiration date: 2015.05.27 14:07:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:33.350 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:06:02 GMT-7, expiration date: 2015.05.27 14:12:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:33.774 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:11:07 GMT-7, expiration date: 2015.05.27 14:17:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:34.174 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:16:00 GMT-7, expiration date: 2015.05.27 14:22:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:34.637 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:21:04 GMT-7, expiration date: 2015.05.27 14:27:58 GMT-7, cancellation date: (null)
2015-05-27 14:27:35.069 StoreKitSandbox[5803:1054853] Transaction: 1000000156919353: product com.foo.StoreKitSandbox.1_month_autorenew_foo, original purchase date: 2015.05.27 14:26:15 GMT-7, expiration date: 2015.05.27 14:32:58 GMT-7, cancellation date: (null)

Can you repro using this diagnostic approach?