The is no API for Bluetooth Classic on iOS. You cannot do this.

Thanks. Is that documented somewhere?

my app relies on having an internet connection while it is running In that case, you have the choice of either checking the receipt on the device or on the server. I guess there are pros and cons to each. Do you have code running on the server to support the app, or does the app just download files? If you have code running on the server you may prefer to extend that to do the checking. What is your threat model? Are you aware of people actually cracking your app? Should I continue using the verifyReceipt endpoint from the device? What you're currently doing will continue to work, but it is not ideal as described above. Should I plan to use the verifyReceipt endpoint from my server? I wouldn't recommend that for new code as it's deprecated. Should I plan to use the App Store Server API and App Store Server Notifications V2? You could do that (though I don't personally know much about that). Your other option is the validate the receipt on the server without communication with Apple. There is a page titled "Choosing a receipt validation technique" here: https://developer.apple.com/documentation/storekit/in-app_purchase/original_api_for_in-app_purchase/choosing_a_receipt_validation_technique

The StoreKit and/or receipt APIs have ways to detect refunds on the device, and on your server. Is this a subscription or a non-consumable IAP? How do you check for the purchase?

How long have you been waiting?

My guess is that they have Arabic in their list of languages Check that. (Ask them to send screenshots of the Settings screen.)

If a user has selected German and Arabic and not English, why do you want to show them English?

Generally you can't; this is a deliberate choice by Apple to increase user privacy.

Question: does your app rely on having an internet connection while it is running for other purposes? In my case, my app generally does not need an internet connection. So being able to verify the receipt without an internet connection is important. But if your app cannot do anything useful without an internet connection then also needing the connection for receipt validation is not a big deal.

Stuff at this level is only documented in man pages The first thing I did after reading your post was man pthread_set_qos_class_self_np there isn’t a man page for pthread_set_qos_class_self_np FB12702048 Does that mean that it's an undocumented function that I shouldn't be using? (Serious question. Recall libcache on iOS and see FB5480758.)

Wikipedia EveryMac.com

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.