Thanks @DTS Engineer ! But unfortunately that only sets the next build number, it doesn't allow me to set CFBundleVersion to an arbitrary number. The issue is that because 2 different apps requires having 2 different workflows, manually setting the two different "next build numbers" to be the same value will get out of sync very quickly.

OK that's very interesting because it's a .webm file with an Opus track. @Media Engineer it sounds like from your POV this should just work the way other audio files do? This has given me enough info to enhance my existing feedback (honestly wasn't sure if this was a bug in my code or lack of support in the OS) - take a look at FB15639450.

FYI you might be able to work around this by turning off echoCancellation which is the suggestion I got on this somewhat similar bug: https://bugs.webkit.org/show_bug.cgi?id=294623

@App Store Commerce Engineer Just to confirm - is the signedRenewalInfo always the latest renewal info for that originalTransactionId ? (as of the notification's signed date; I understand notifications can come out of order) I'm not sure what else it could be, but since I fundamentally misunderstood signedTransactionInfo it seems worth checking!

Yeah, this is very annoying (filed FB12010677 about it). We use URL(string: "x-apple.systempreferences:com.apple.preference.notifications")! which gets you pretty close — the user still has to scroll down and select your app though.

Thanks for your reply! I’m interpreting what you’ve said to mean “the user’s App Store account has been deleted.” None in particular seemed suspicious, I was just a little surprised at the incidence rate for this error code. Among our receipts is slightly more than 1/1000, which seems a little high to me. But frankly the major confusion was I had 21010 down as “unauthorized” rather than “account not found” and I thought the difference in error code was strange. Thanks @App Store Commerce Engineer

@eskimo Thanks for the detailed answer! I feel like I understand the tradeoffs now. I appreciate that Apple has internal style to stick to & whatnot, but in my personal opinion this bullet point would much enhance the technote: URLSession is very much focused on HTTP, and WebSocket isn’t an HTTP-like protocol. While it uses HTTP under the covers, the actual WebSocket protocol is a reliably bidirectional connection with message framing. Those semantics are a much better match for NWConnection than URLSession. That really cleared up for me why it was a generally good starting point, rather than "start with URLSession & use NWConnection when you need something special". One last bit if you don’t mind — is there official documentation/tutorial/walkthroughs/etc. that explain making a WebSocket connection with NWConnection? It looks a bit more complicated to setup than URLSession & is definitely less familiar to me.

@Jason This Technote is awesome. Is there any explanation of this recommendation? Unless you have a specific reason to use URLSession, use Network framework for new WebSocket code. That seems like the opposite of what I would expect, so I'm curious to understand why we should prefer Network framework over URLSession for websockets.

Note: I have also attempted this with Xcode 13.1 which yielded no difference.