User Profile

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.

There's little documentation on this, so after using a support request I now know:This is as-designed. If you do not specifically set the value of automaticSpellingCorrectionEnabled, on an NSTextView then the value for NSAutomaticSpellingCorrectionEnabled in global domain (i.e. System Preferences) is used. However this is a read-only process and changing the menu state in your app will not update the global value, so it needs to be stored locally. Note there is no global preference for "Check Spelling While Typing" (continuousSpellCheckingEnabled) and this is assumed to be NO by default.This is also as-designed. It's up to the developer to set the values on each NSTextView as required.It is necessary to override:- (void)toggleAutomaticSpellingCorrection:(id)sender- (void)toggleContinuousSpellChecking:(id)senderin the NSTextView subclass to handle the user's interactions with these menus and save the new values as needed. Remember to call super at the end!