I believe that the last iPhone without Bluetooth Low Energy was the iPhone 4, which launched in 2010. Its current market share is zero.

The is no API for Bluetooth Classic on iOS What I should have written was "there is no API for things that you actually want to use, like serial ports, on Bluetooth Classic". Yes you can do GATT over classic - I had forgotten about that - but I'm not actually aware of any practical use for it. arduino file includes "bluetoothSerial.h" That doesn't look promising.

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.