I can only type 500 character comments so I'll reply with a couple messages. Yes, the tokens are all different. I stuff each arriving token into a lookup to prevent replay (incidentally, this was one of my first learnings with DeviceCheck, that tokens will pass validation with apple's servers no matter how many times you send them up!). Sounds like you have experience with this as well

"What happens if I get a pile of tokens from users of my app, and use them in fake requests to your server pretending to be from your app?" I was wondering if this was the case. I use public key pinning in my clients to make it hard to drop mitmproxy in front of the app to harvest tokens, but perhaps they have worked around this. I'll experiment with token expiry on Apple's servers to see if a scripter could accumulate a pile of them in time before they expire. I appreciate your thoughts!

"Have you also used AppAttest?" I have not, because our client is used in macOS apps too, and AppAttest isn't available there (I don't really understand why, because I don't see that in the docs, but DCAppAttestService.shared.isSupported always returns false on macOS) Perhaps I should offer it as an enhancement for iOS customers

"Based on my experience, I'd say you shouldn't expect to get any useful help from DTS (nor Feedback Assistant, nor anyone else at Apple) for problems like this. If they do have a weakness, they probably already know about it and they aren't going to discuss it with you." I feared this, but I'm crossing my fingers anyway! Again, thanks for your input

Great, thank you!

I'm not entirely sure when the unverified transaction fires. I'm putting some analytics in prod as @endecotp suggested to get stats. P.s. did you mean to guard the unverified case before returning?

Darn, I was hoping I could ignore that entire case. But as you suggest a false positive would be a really bad UX for a legit user if I just dead-end the app. Thanks for the reply! One thing I'm considering is performing my own receipt validation on the backend for the unverified case. Then if the unverified branch is entered + receipt validation fails, I'll feel OK about marking requests from that app as fraudulent.

Thank you for posting your working code :)

I've had it in prod for a 6 days now and it's been working great. I'm going to make this the default in my SDK for all our customers to use. Thanks again Quinn, we are lucky to have you on the forums!

Yeah, not much there about the unverified branch :/ Edit to add: Oh, I missed the last bullet there that we are supposed to call refresh with an unverified result. That's interesting! I figured once unverified it would stay unverified. I wonder in practice how often the case flips from unverified to verified during a refresh()

I'm def interested!!