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

does the Apple Developer programme support sole traders who are VAT registered in the UK? Yes, but with one proviso: you cannot use a "doing-business-as" pseudonym. I.e. if your name is actually John Smith but you like to refer to your business activity as Cromulent Enterprises, then tough; Apple will refer to you as John Smith throughout the app store. I was a (UK) sole trader when I first started selling apps, and I actually started a limited company in large part in order to get a more corporate name in app store listings. Of course as soon as I did that, Apple de-emphasised the business name in the app store listings; previously they were shown more prominently alongside app names. Being a one-person limited company involves a bit of bureaucracy, i.e. PAYE - it's more work than being VAT-registered, for example - and you have to pay employer's National Insurance, unless you have a second employee. Think twice (get advice) before doing it. DUNS numbers are not required for non-company enrolment. Note that in the US, they have a concept called "disregarded entities" - as I understand it, you can create a company which is sufficiently real that it gets a DUNS number and can register with Apple as a business, but it is "disregarded" for tax purposes, i.e. you are a sole trader as far as tax is concerned. It may be that this is the reason why UK sole traders are not handled quite as you might like. VAT registration or not doesn't change anything. (Disclaimer: I've been a limited company since 2018, things could have changed.)

According to: https://www.apple.com/newsroom/2024/05/app-store-stopped-over-7-billion-usd-in-potentially-fraudulent-transactions/ “In 2023, Apple terminated close to 118,000 developer accounts” I guess yours is going to be one of those for 2024. There’s probably nothing you can do about it. I find this constantly terrifying; my income is at the mercy of some stupid AI chatbot. The lesson is, always make sure you have a backup career plan!

[quote='789401022, on-d-go, /thread/756183?answerId=789401022#789401022, /profile/on-d-go'] If I've opened a file descriptor with a filepath, I need to know if or when it's not reading/writing from/to that filepath. My question still is: Do you know if there's a high-level API, included with iOS, macOS, and tvOS that does: func fileDescriptor(_ fileDescriptor: System.FileDescriptor, pointsTo filePath: System.FilePath) -> Bool { // } [/quote] I think your stat/fstat code is OK. I don’t see equivalent methods on the swift fd struct, so I guess there is no “high level API” in that sense. Are you keeping this file descriptor open for a long time? If not, I suggest trying to write atomically. Create a temporary file, write your data to that file, close, and then rename to the destination. Rename is atomic; there is no opportunity for e.g. another process to rename the file while you are writing to it. Otherwise… what is the underlying reason for this requirement? In the situation where the user has deleted the file, maybe the user doesn’t want it to reappear? Most programs do not detect / handle this case.

[quote='789258022, on-d-go, /thread/756183?answerId=789258022#789258022, /profile/on-d-go'] I would expect fileDescriptor1 to read from file1 [/quote] As I wrote in my original reply, Why would you expect that? The behaviour of file descriptors is well-defined. The behaviour you are seeing is allowed by the spec. What’s actually happening is that the kernel is allocating the same FD for the second open as for the first, which it can do because you closed the first one. So when you read, you read from the second file. What are you actually trying to achieve here? There may be other APIs that better match your requirements. If you really want to use file descriptors you need to understand them properly. You will be constantly surprised if you try to guess how you would expect them to behave.