If something builds for arm64 macOS, shouldn't it work with iOS/iPadOS, which is also arm64? No, unfortunately not. I thought you included it and that making libjxl work on iOS is an easy/supported process. I do include it in my iOS app at runtime. Doing so was not a particularly easy process. I used something from github called "ios-cmake", which is a pile of scripts and/or cmake configuration fragments.

That cmake invocation will build macOS libraries I think. I'm not a cmake expert. Search github for "ios-cmake".

https://www.apple.com/uk/newsroom/2024/05/app-store-stopped-over-7-billion-usd-in-potentially-fraudulent-transactions/ Apple terminated 118,000 developer accounts in 2023, down from 428,000 in 2022. That's one every 5 minutes. There are lots of posts like yours on this forum. I don't recall anyone ever replying to say that their account was re-instated. The moral is, don't be a full-time Apple developer; make sure you have another job that pays enough to pay your mortgage and the bills. Just treat your income from Apple as a nice bonus that could go away at any moment.

This is not a general problem; I've found reviews to be fast recently. (Only 20 minutes in one case!) I guess either you have hit some sort of "special review", or something has got stuck. Sorry, I don't know what you can do about it.

No, Yes, No.

I'm using the JPEG XL reference implementation - https://github.com/libjxl I'm creating GPU textures from the decompressed images, so UIImage is not a concern. I've found this to have reasonably good performance, certainly better than the open-source JPEG200 implementations, but not as good as libjpeg-turbo for regular JPEGs. I've not compared it with decoding PNGs.

My current system creates a unique key for each user-device combination, and uses that to encrypt assets at rest. OK, so these must be assets that the app downloads, not things that are included in the bundle that you distribute, right? I was referring to assets, like game graphics, sounds etc. that are in the app bundle. With your scheme, make sure you test what happens when a user gets a new device and your app is copied over automatically for them. Do the keys get copied over too? Do they still work? This has caused me pain. In particular, users may not use your app for some time after getting the new device and not associate the device replacement with the app not working anymore.

What sort of images are they? Are they continuous-tone, or paletted? I have had good experience using JXL, which has a lossless mode. Its lossy mode with a high quality setting could also be useful. Re video codecs, you should investigate what people are using for screen recording.

Will I get rejected by App Review for obfuscating a small portion of my code? No, since they don’t see your source code. I don’t think reverse engineering is something you need to worry about. It will almost always be easier for someone to re-implement code than to reverse-engineer it. There are some exceptions, including when you have server communication, and the attacker wants to pretend to be your app when talking to your server. Of more concern is extracting non-code, for example the expensively-designed graphical or sound resources in a good game. If you really think that someone might want to steal your (source) code, I think attacks like phishing or guessing your github password or supply-chain attacks could be of more concern.

Users can turn off PAT in Settings. For a website, you can fall back to CAPTCHA etc. What does an app do? I believe they also don’t work when the app is in the background. If my goal is to minimize if not eliminiate fraudulent/malicious use of my app's API As I’ve written in various threads about AppAttest, you need to consider what level of false-positives (i.e. legitimate users who fails your tests) is acceptable for you.

There were similar questions last year when the last update came out. Here is one thread; I think there were others (but the most useful ones were on the MacRumours forums): https://developer.apple.com/forums/thread/731398 As I recall, the answer is (1) the .ipsw is useless, (2) you can install the current macOS on your new volume and then upgrade to the beta from that, (3) there is some dodgy unofficial website that can make it easier, if you trust them. Oh and (4) if you have the same M1 Mac Mini as me and the volume you want to use is on an external USB disk, you need to connect it to the correct USB port. Good luck!

Oh wow, a reply! I'm actually in the process of removing AppAttest from these apps because it has proved too unreliable, and I got no useful responses to my bug report or posts here. I've already removed it from one app and I've literally been doing that for the second today. Even a quite small rate of false-positives from App Attest is enough to get 1-star reviews from users and consequently a crash in sales. Anyway, to answer your questions: Are you ensuring that you are calling attestKey after generateKey has succeeded? Both of these methods are async, so you should not be attempting to synchronously call one after the other. Yes. I was even extracting the key ID (see the FB). As to the DCErrorInvalidKey, that indicates: keyId is nil keyId is invalid (i.e., from a previous App installation) That does not explain what I was seeing. I asked above, could it indicate a cracked device? If not, how is a cracked device expected to behave? I.e. at what point would I get an error? Anyway, thanks for your interest in my problems, even if it has come too late to be of any use. P.S. my FB number, with more details, is above. That includes links to some other forum posts reporting related problems.

.activityType property? It was the default value - .other. You should definitely fix that - otherwise, you may find that locations get snapped to roads or otherwise messed with! If your app supports orientations other than portrait you definitely need to use .headingOrientation. Regarding true vs. magnetic, my recommendation is to get the magnetic data from iOS and do the conversion to true yourself (e.g. using GeographicLib). We don't know how Apple is doing that conversion. None of those things explain what your user is seeing, though. The important question is, which is right, the Compass app or your app? If you'd like to share the identities of either your app or the 3rd app, I'll compare them with mine.

Still not working, 2 months later. Burner phone time I think.

My main query is whether you can supply a VAT number on an individual account Just to address that - your sales are to Apple Ireland, i.e. they are international. So no VAT is involved. You do not need to tell Apple your VAT number, nor they tell you theirs. (People often get confused by this!)