None of this works. (If it did work, and to learn more about how close you can get to making it work, ask somewhere else. This is an official Apple forum. People discussing how to run Apple software on non-Apple hardware have those discussions elsewhere.)

to validate the receipt data, calls the verifyReceipt endpoint So you aren't doing on-device receipt validation. You're sending the receipt to Apple for validation. Communicating with the App Store servers from the app is ... not how I do it. I believe you have to embed your "shared secret" into the app, right? That is ... an interesting security decision. Anyway regarding the current change of SHA algorithm in the intermediate certs, I do not believe it will affect you as you are not doing certificate validation on the device.

pthread_set_qos_class_self_np Thanks Quinn! That seems to be working. This stuff was surprisingly difficult to find out about. The developer.apple.com search can't find anything for pthread_set_qos_class_self_np even if I know the name of the function. DuckDuckGo found this page: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/EnergyGuide-iOS/PrioritizeWorkWithQoS.html which is quite useful, but it's in the "documentation archive" (i.e. documents that look like they were written by intelligent humans, not just scraped from headers by a bot) and I think is therefore excluded from search. But that suffers from the usual problem of telling you everything except the name of the header that you need to include. Sigh.

Can I use the NSThread setThreadPriority class method for a thread that was not created using NSThread? In a quick test, I still see the warning after using [NSThread setThreadPriority:]. So maybe it must be an NSThread.

How did you create that thread? If, for example, you used NSThread, you can set the qualityOfService property. Ah-ha, thanks. Actually I am probably using a std::thread in most cases. Can I use the NSThread setThreadPriority class method for a thread that was not created using NSThread?

You may need to make changes to your on-device receipt validation, depending on whether your existing validation code will work with the new intermediate certificate or not. If your existing implementation understands the new intermediate certificate, then you have nothing to do. How are you validating the certificate? Are you using e.g. libssl?

OK. That surprises me. Does this generally work for people? In appleid.apple.com, under "personal information", it shows Country / Region = United Kingdom and Language = English (UK). But on that same page, it shows my birthday in the US format "MonthName DayNumber, Year". Can someone else not in the US check what they see there? I do sometimes change the region setting on a device to US, or somewhere else, for testing, but I guess that is independent of the Apple ID settings, right?

Post the complete email headers here and someone will probably be able to confirm/deny. Remove your own domain name if you like. Important: do not ask Apple Developer Support if it is genuine; do not use the report-fishing email address. The former is unable to correctly identify their own emails, and the latter does nothing at all.

Scott is right. I thunk you misunderstand what weak variables are.

the links provided directly link to installer files on Apple's swcdn.apple.com website No, it's a link to a site called "mrmacintosh". Maybe that links or redirects or something to Apple when you visit it. Who knows what it links to when I visit it. Maybe it checks my IP address, and sends me the malware if I'm one of the victims that someone is trying to hack. It is very unwise to use things like this - an amazingly dangerous of Apple to make it possible by apparently providing these "secret" installers.

I recommend GeographicLib for this sort of thing. It seems reliable, and if you did find any bugs you have the source so you can fix it yourself.

Can you give assurance that the usage in Apple implementations are secure? Read Apple's license agreements - you'll find no assurances about anything, as is the industry norm. I believe the pentester ran a grep command to find which binaries are possibly affected. Right. I guess there's a whole range of people offering these services out there. Some will be e.g. ex-NSA people but you can't afford them. Then there are some kids who run a few greps over your binaries and produce a semi-automatic report. You can afford those but they don't tell you much. Really you need for the people who prepared the report to answer these questions for you, rather than just giving you the output of the grep and sending you here. FWIW, IMO, you should ignore these reports when they are in Apple's code. What is your threat model?

https://mrmacintosh.com/macos-sonoma-full-installer-database-download-directly-from-apple/ You trust that site? Who owns it? Note to Apple: you not providing a proper installer endangers developers who will end up installing potentially dangerous hacks like this one.

That’s not allowed. They will reject the app if they are aware of what you have done.

I am not sure if there is a way to create and delete users programmatically The page that you linked to says: you cannot add or delete them directly. Go to App Store Connect to create a new sandbox tester Apple ID. Do I need to regenerate the JWT token every 30 days? No. Much more frequently. I think the max validity in mist cases is 20 minutes. This is described in the documentation.