https://www.sqlite.org/lang_datefunc.html

The old XML API required checksums for screenshots, and in fact I think the Transporter uploader relied on comparing checksums to determine whether to actually send the file Events are newer and weren't supported in the XML API. Fundamentally the answer is "it just does".

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