simulatesAskToBuyInSandbox does not change StoreKit behavior

Same here with iOS 9.0 SDK

Same here, with iOS 9.3, on Xcode 7.3.

Same here, with iOS 10.1.1, on Xcode 8.1.

Thread bump here...

Even the latest WWDC session is quoting this as should work

http://asciiwwdc.com/2016/sessions/702

"So if you want to test your deferred transaction in Sandbox, it can be done using SimulatesAskToBuyInSandbox.

This is where you create your SKMutable payment object.

You pass in that product and then you set the SimulatesAskToBuyInSandbox flag.

This is a flag that's going to tell the App Store, hey, treat this as if a child was buying this and that child was part of a family."

StackOverflow is full of unanswered/unfinished questions on this subject. It would be nice to get an official answer.

The AskToBuy simulation doesn't work in the sandbox. Here's a posting I did a while back and the information remains true

With regards to Ask-To-Buy support, there is no support for this function in the Sandbox nor in the TestFlight environment. “Ask to Buy” is not an API implementation, but a support process implemented by iTunesConnect which requires StoreKit interaction with a specific iTunes account. This support only exists in the production environment. I suggest that you submit an enhancement request - via the Apple Developer bug report web page - http://bugreport.apple.com

The primary reason for wanting this support is to be able to test the “Ask To Buy” purchase process. This makes sense, but I have no way to simulate this process. Instead, I can only advise you that in the “Ask to Buy” scenario - that the application not assume that after a purchase via the addPayment method, that the transaction will be either immediately successful or a failure. Instead, the “Ask to Buy” scenario means that the application won’t know until “later” (which could be hours later) of a formal response.

The simple means to support “Ask to Buy” - call the SKPaymentQueue -addTransactionObserver once in the didFinishLauchingWithOptions delegate method and never call the removeTransactionObserver method - make sure that the observer is always active. When the application is frontmost and the transaction response is available, it will be passed to the updatedTransactions delegate method.

Some additional notes - “Ask to Buy” purchases are only deferred for 24 hours. If the parent does not approve (or fail) the “Ask to Buy” purchase within 24 hours, the app can assume that the transaction will never complete. The application is not notified that the transaction failed due to inaction. It is also the responsibility of the app to track this 24 hour timeout period.

If a user initiates multiple “Ask to Buy” purchase attempts, each new request for the same item, overwrites the previous request and restarts the 24 hour timer. This is to prevent multiple purchase requests from accumulating.

The application will receive notice of the approved (or failed transaction if the parent denies the request) using the transactionObserver mechanism. This means that the app must either be re-launched, or moved from the background to the foreground. There is no call to the updatedTransaction delegate method if the app is active at the time of purchase approval.

By the way, if you like, please submit a bug report to the iTunesConnect product that the AskToBuy simulation doesn't works as described in the WWDC video.

http://bugreport.apple.com

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Let's continue our discussion on 'best practice' and 'better than best practice'

IMHO - As a general rule I do not like to load memory with lots of classes that do not need to be loaded. In your 'best practice' you, and Apple, recommend always leaving open a transactionObserver. That means that you have to instantiate and leave in memory the delegate for that transactionObserver. Not my 'best practice'. So I simply give the user the option of 'check for approved purchases' (as an option after tapping 'In App Purchase Info' along with the options 'check price' and 'already purchased - restore' and 'not at this time') . If they chose that option then I open a transactionObserver and the transactions, if any, flow in.

I also differ from you in the following way - please correct me if I am wrong:

You wrote - "This means that the app must either be re-launched, or moved from the background to the foreground. There is no call to the updatedTransaction delegate method if the app is active at the time of purchase approval." I believe that any and all queued transactions will call updatedTransactions within moments of executing an addTransactionObserver.

I would like to add a correction to my response from 3 years ago. An application can set the simulatesAskToBuyInSandbox to true and the application will see the .deferred event at the updatedTransactions delegate method. However, there is no mechanism to associate a test account with a parent account which will authorize the Ask-To-Buy transaction. In the sandbox, after the .deferred event is processed, the app will receive the .purchased event.

Something to consider, there is a difference between the simulated Ask-To-Buy process in the sandbox, and how the production Ask-To-Buy process works. in the production environment - if the Ask-to-Buy purchase is started and the parent consents to the purchase, the app used to make the Ask-to-Buy request must be backgrounded, then brought to the foreground. This will trigger the transactionObserver to check the App Store for the new transaction on the app queue. If the app used to make the Ask-to-Buy request is left in the foreground while the parent approves the purchase, there is no push notification and the transactionObserver will not check for the newly queued transaction. The "child" user must either quit the app and relaunch it, or background the app and bring it back to the foreground for the approved transaction to be detected on the app queue.