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?

flutter Is it possible that your app “shares a similar binary” to every other app written using flutter?

I think I understand the current behaviour. So why was it different before? One thing that has changed is the switch from bash to zsh as the default shell - but that shouldn’t matter if you were explicitly invoking /bin/bash. I don’t believe that the bash or ssh behaviour has changed. Mysterious. Re this example: /usr/bin/ssh max /bin/bash -c "ls /Volumes" That runs this command on the remote machine (note no quotes): /bin/bash -c ls /Volumes According to man bash, the effect of bash -c is that “commands are read from the first non-option argument command_string. If there are arguments after the command_string, the first argument is assigned to $0 and any remaining arguments are assigned to the positional parameters. The assignment to $0 sets the name of the shell, which is used in warning and error messages.” So your command just runs ls, while (uselessly) setting $0 to /Volumes. You want to run /bin/bash -c ‘ls /Volumes’ which is what your final version does.