I'm seeing the same thing for a few recent Xcode releases. Happens when calling MTRegisterProfessionalVideoWorkflowFormatReaders(); inside AppDelegate init. Filed as FB12137794

I've been told this is a bug so I've filed a report.

I will post the result of the TSI here for future reference.

That's exactly what I am doing!I will raise a support request to confirm my suspicions but I think that what's going on here is that Apple is incorrectly setting the state to "purchased" when it should still be "purchasing" if the transaction has not actually completed. That feels like a bug.Even though I'm finishing the transaction on the first state change to "purchased", it doesn't really make any sense that the app should get another notification from "purchased" to "really purchased" does it.

Not quite. There was only one change of state to "purchased" and that happened soon after the customer chose to purchase. But the point is that at that moment the purchase was not actually confirmed, it was only pending. It was 9 hours later when the transaction changed from pending to confirmed. That is the moment when it would be reasonable to expect the app payment queue to receive the notification rather than when it did.As per recommended practice, I'm calling finishTransaction only for purchased/failed/restored states (although restored isn't applicable anyway for consumables). I'm aware that the inapp data only contains "unfinished" purchases (which is why it is useful for adding the purchase to an online account) but I can see there is a timing risk if Apple's server doesn't respond instantly. Since the app finishes the transaction when it receives the 200 OK response from my server, that could possibly cause that purchase to be removed from the receipt by Apple before the decoded receipt is sent back to my server.Or am I misunderstanding things and the decoded receipt sent from Apple server to my server is simply the receipt uploaded from the app without any modification? In that case, that receipt will always be before the transaction has been finished, so there is no timing risk.However I feel that scenario isn't applicable here because surely the inapp data should have been empty anyway if the purchase wasn't going to be confirmed for another 9 hours? This is what I'm trying to get to the bottom of.

Yes the one customer I had communications with did send me the invoice that he received when the purchase was no longer "pending".Only the state changing to "purchased" causes the receipt to be sent to our server, that's why I know the state changed to "purchased" even though payment had not actually completed and customer said it was "pending".Yes the app observes the payment queue all the time.finishTransaction is passed the transaction that it received on that notification, in the usual way.