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.)

No, I don't think that's available.

Are they rejecting all new VPN apps?