The clue is in the name, isn’t it? I would not expect a “local identifier” to be valid on a different device. The change on iOS update seems less reasonable.

is there a way to create a Date constant from year, month and day? No, because the bizarrely-named Date type isn’t a date, it’s a time-point. Everywhere that I use Date in my code there’s a comment saying “actually a DateTime”. If you want to represent a date (only), don’t use Date. I suggest writing your own type that contains either year-month-day fields or a Julian Day Number. I'm used to Python which has both naive and aware (of time zone) date time values. Does Swift have a naive date time concept? There is also DateComponents. You’ll probably get frustrated by not having exactly the combination of features that you want, and unless you are constantly passing these things to and from Apple APIs, you’ll end up writing your own replacement.

Right, so IIUC LSMinimumSystemVersion is the macOS version on which your app should run in "made for iPad" mode. There's a different key for the minimum iOS version. Generally you should set this in Xcode's "general" tab in "build settings", rather than directly in the info.plist.

App Store Connect can show the exact proceeds that you will receive in each region for any price. For example, if I select a price of 100 EUR for Germany, it shows proceeds of 71.43. That can be explained as 100 / 1.19 = 84.03 (i.e. VAT of 19%), and then 84.03 * 0.85 = 71.43 (i.e. Apple's "small business" commission rate of 15%). Neither of your examples is correct, because 21% VAT on a VAT-inclusive price of €100 is not €21!

iOS or macOS?

I'm using App Receipt hash to key some information server-side. do you get a newly generated one with possibly minute differences that would yield a different hash Why even consider using the hash as your key? It seems a very odd choice to me. Why not the "original transaction identifier", or whatever it's called?

Presumably this is sufficiently deep that there is zero GPS signal. How do you believe that the Android system is determining the location?

Is it possible to get a new receipt that would yield a different hash for the same transaction? Probably yes.

we bind the user to the attestation key Don't do that :-(

equip your servers with a standard CA-issued digital identity and then implement certificate or public key pinning on the client side. Quinn, do you have any comments about the use of that approach on e.g. corporate networks that have “MITM” proxies? The Wikipedia page for pinning says “Most browsers disable pinning for certificate chains with private root certificates to enable various corporate content inspection scanners”. Does that happen with these APIs? Did you see this thread, where the developer might be encountering this issue when App Review run his app: https://developer.apple.com/forums/thread/773444

The doc you linked to says: "This change will only affect TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS and tvOS." So I'd say this does not apply to your "Private CA root certificates". But I'm not a TLS expert.

Interesting. Do you try to generate a new key after getting the "invalid key" error? What happens? I tried to use AppAttest for a long time but it always failed in some impossible-to-debug way for a small minority of users, and eventually I gave up on it. I'm not sure if I ever considered this scenario. One problematic situation that I did worry about was when a user replaced their device and set up the new device from a backup of the previous one; it would get the key ID from the old device and fail.

sessionReachabilityDidChange ... doesn't wake up the phone app. Or maybe it does... this stuff is all horribly difficult to debug!

is it allowed for an app that has "when in use" location permission to turn on background location updates when it is already in the background? This does seem to work. I guess I send (messages from the watch to the phone) from appropriate WKApplicationDelegate methods Sending a message from applicationDidBecomeActive doesn't work because the phone isn't reachable yet, but I can send the message from WCSessionDelegate.sessionReachabilityDidChange, shortly later. applicationWillResignActive works OK. So now the phone knows when the watch app is alive and it's useful to send state updates, even when it (the phone app) is in the background. I think what I have is probably equivalent to watching sessionReachabilityDidChange from the phone, except that that doesn't wake up the phone app. Maybe it should? Thanks.

The fact that both of these exist implies that IAPs can have a different base territory than the app itself, and that different apps can have different base territories, or even that different IAPs in the same app could have different base territories. Is that actually true? Yes. For example, I have an US-focused app and a UK-focusd app. I set the base territories to US and UK respectively, so that the pricing is stable in the places where most of the users are. (I've not tried to do this for IAPs, but the same logic applies.)