Do multiple transactions created or modified within a certain period be emitted as a single Transaction.updates event?

For implementing a Store functionalities and tests by using StoreKit2, I have a task listener and two testcases.

The first one is waiting the update notification before processing the next SKTestSession operation.The second one is not waiting the update.

I looked update events theree times on first one, and twice on second one.

My question is, "Do multiple transactions created or modified within a certain period be emitted as a single Transaction.updates event?"

Task listener

Testcase1

Testcase2

Up vote post of syatyo Down vote post of syatyo
1.1k views
Posted by
syatyo
Reply
Add a Comment

Accepted Reply

The behavior you're seeing appears to be expected. Transaction.updates will always emit the latest updated transaction that StoreKit is aware of. There will always be a delay between a transaction updating on the server, and StoreKit emitting the transaction. With StoreKit Testing in Xcode and StoreKitTest, this delay is much less compared to the App Store or sandbox environment, since these environments are local to your device rather than on a remote server.

If a transaction updates happen in very quick succession as in your second test case, you may only receive a single new value for each unique transaction ID from Transaction.updates because of this delay. These values will always reflect the latest state of the transaction.

Posted by
Frameworks Engineer
Up vote reply of Frameworks Engineer Down vote reply of Frameworks Engineer
Post marked as solved

  • Thank you for the comment. It seems strange to write test code that takes into account the delay of StoreKitTest, so it looks better to wait each Transaction.updates by XCTWaiter, as in testcase1. What do you think about it?

    —
    syatyo

  • That sounds like a good plan to me. After the XCTWaiter you may want to add an assertion in between each call to the SKTestSession methods, to verify your store model is updating correctly for each purchase or refund event.

    —
    Frameworks Engineer
Add a Comment

Replies

The behavior you're seeing appears to be expected. Transaction.updates will always emit the latest updated transaction that StoreKit is aware of. There will always be a delay between a transaction updating on the server, and StoreKit emitting the transaction. With StoreKit Testing in Xcode and StoreKitTest, this delay is much less compared to the App Store or sandbox environment, since these environments are local to your device rather than on a remote server.

If a transaction updates happen in very quick succession as in your second test case, you may only receive a single new value for each unique transaction ID from Transaction.updates because of this delay. These values will always reflect the latest state of the transaction.

Posted by
Frameworks Engineer
Up vote reply of Frameworks Engineer Down vote reply of Frameworks Engineer
Post marked as solved

  • Thank you for the comment. It seems strange to write test code that takes into account the delay of StoreKitTest, so it looks better to wait each Transaction.updates by XCTWaiter, as in testcase1. What do you think about it?

    —
    syatyo

  • That sounds like a good plan to me. After the XCTWaiter you may want to add an assertion in between each call to the SKTestSession methods, to verify your store model is updating correctly for each purchase or refund event.

    —
    Frameworks Engineer
Add a Comment