13

Does the AppStore send out a transaction when it auto-renews an auto-renewable subscription? If so, can it reliably be detected by an App the next time the App loads if it sets itself as an observer:

[[SKPaymentQueue defaultQueue] addTransactionObserver:self];

Will the new auto-renewed transaction make a call to:

-(void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions

with transaction.transactionState==SKPaymentTransactionStatePurchased?

If so, great. If not, does this mean you must examine all transactions every time an auto-renewable subscription approaches expiration using:

 [[SKPaymentQueue defaultQueue] restoreCompletedTransactions];

Thanks...

Peter Kramer
  • 231
  • 3
  • 7

1 Answers1

12

After some research I can answer my own question and raise another related issue. The App Store calls the paymentQueue and posts a transaction. The transaction is posted with transaction.transactionState==SKPaymentTransactionStateRestored, not transaction.transactionState==SKPaymentTransactionStatePurchased.

The issue is that unfortunately this gets posted only to one device. A second device does not get the posting. Therefore, to detect the auto-renewal, or rather to detect the lack of an autorenewal and deny the device a continuing subscription, you have to do a restoreCompletedTransaction or "http post a 64-bit encoded JSON containing the last transaction". If the fomer, the user needs to give their password; that's intrusive. If the latter, lots of additional coding is required. So, my question is...why doesn't StoreKit have a command:

(does not exist) - [[SKPaymentQueue defaultQueue] restoreAttachedTransactions:(NSArray *)transactions];

This command would flow just like a restoreCompletedtRansactions but it would only restore the attached transactions and, most importantly, it would not require log-in by the user. It has the same security protection as the "http post a 64-bit encoded JSON containing the last transaction" and it allows the entire In App Purchase process to be done in StoreKit rather than requiring web posting code.

If this makes sense to you, please suggest how to get this to Apple....thanks.

Peter B. Kramer
  • 196
  • 3
  • Firstly thank you for clarifying that for me. Been searching for half an hour or so. Why is that so badly (not at all) documented by Apple?! Maybe it is somewhere, but not in the System Guide "Auto-Renewable Subscriptions" which would be the logical place for me?!? – Rich Dec 08 '11 at 14:15
  • Secondly, I see your point but maybe there's a flaw in your thinking? On the second device where are you going get the the argument "transactions" from, to send to your wish-api? Without paymentQueue getting called in the first place you don't yet know what the new transactions are. Your suggestion (I think?) would at best be useful for restoring only a subset of previous "known" purchases. But even then, it's reasonable to expect the user to have to enter his/her password. No? – Rich Dec 08 '11 at 14:22
  • The way we do it (at least until now for consumable purchases) is by offering the user the "option" (very important - optional!) to register on our website. That way, on the 2nd device, we'd already know that the subscription has been renewed and the app can go ahead and (offer to) download the most recent issues. – Rich Dec 08 '11 at 14:27
  • Thirdly, with Newsstand, that all becomes history anyway! :-) – Rich Dec 08 '11 at 14:28