in the App store and underneath the App icon You set those two things in different places. The app store name is set in the App Store Connect web interface. The name under the icon is set in Xcode. I think both can be changed in an update but I’m not certain.

Have you tried on an actual device, rather than the simulator? How are you sending the notifications? From an actual server, or using Xcode to send them locally?

IAP pricing is due to be overhauled soon; wait for these changes and see what becomes possible. In the meantime - do any of the “alternative” price tiers work for you?

This?: https://www.theregister.com/2023/02/16/google_delays_certificate_transparency_log/ Google changed the format of their CT log on feb 15th, but have now changed it back because it broke things.

Even if location updates are allowed in the background, they stop shortly after app is not in use. That shouldn't happen. It seems you have not successfully enabled background location mode.

Please post your actual code. What width and height are you actually passing? What have you changed in the third line? You don't want kCGBitmapByteOrderMask. You need to pass one of the actual byte order values, e.g. kCGBitmapByteOrder16Little.

Is this something to do with Certificate Transparency policy? Something changed last April. What is the start date of the cert?

Something to be aware of is that external GPS devices, connected using Bluetooth, can sometimes supply fixes faster than one per second. Beware, this can reveal bugs in your app!

I've just filed a bug report for this: FB11992786 None of these work: -u USERNAME -p PASSWORD -u USERNAME -p PASSWORD -asc_provider SHORTNAME -jwt JWT -apiIssuer ISSUER -apiKey KEY But -m diagnostic does pass, with username and password.

The site that used to be called "App Annie" could do this for you. There are probably others.

You are right to worry about this. It is not difficult for users to access the app's data files. (They can access them on iOS too, though it takes a bit more effort.)

No, I don’t think so.

See also: https://developer.apple.com/forums/thread/708407

My assumption is that this works using a "chain of trust" of some sort, i.e. the (immutable) bootloader computes a signature for the kernel before it loads it, and the kernel computes a signature for the app before it runs it, and when App Attest runs it sends these signatures to Apple. You can avoid replay attacks with nonces and timestamps and so on. There is plenty of public material available describing how to do "trusted computing" on, for example, UEFI bootloaders loading Linux; I speculate that what Apple is doing for App Attest is similar in most respects. Edited to add: the term to search for is "Remote Attestation". This will find a variety of e.g. academic papers, stack exchange answers, etc.

You will need to upload the "what to test" info separately using the App Store Connect API. (Or just use the website.)