Does anyone know how IAPs and receipt validation is supposed to work when an iOS app is run on a new Arm Mac? I have an iOS app which I'm pleased to discover runs well on my new Arm Mac mini. The app has non-consumable IAPs. At startup it parses the app receipt. A receipt is present, but my existing receipt validation code decides that it has the wrong hash. (This is with the app installed from the App Store, not a local build.) I'm aware that receipt validation is different for native Mac apps, including catalyst apps (e.g. getting a device GUID from the ethernet MAC addresses etc.) But what is supposed to happen in the case of a regular iOS app running on macOS? Is this documented anywhere? Has anyone got IAPs working, with local receipt validation?

Is there a recommended way to determine whether to use the development or the production server API endpoint for DeviceCheck? For App Attest, the authenticator data includes either "appattest" or "appattestdevelop" in a field of the cbor data. For IAPs, we're supposed to try the production endpoint and then retry with the development endpoint if we get a particular HTTP status code. But the docs for DeviceCheck say only to use the development endpoint in development and the production endpoint in production. What are others doing? Is there any clue in the docs that I have missed?

I have an App Attest server implementation which is generally functioning well. From time to time, however, I get receipts which do not refresh when I send them to Apple's server; I get a 404 response. The docs (https://developer.apple.com/documentation/devicecheck/assessing_fraud_risk?language=objc - "Understanding HTTP Response Codes") say this means "No data available for the supplied receipt". Once a receipt is in this state it seems "stuck" i.e. it will never return a new receipt. I have seen this for both the development and production environments. Does anyone know what this means, and what I should do?

Dear Apple, I know that content moderation is difficult, but surely you can do better than this. You seem to have a very crude profanity filter that ****s out words with perfectly normal dual uses, but you can't stop the constant stream of adverts for c all girls in D ubai. Come on, sort it out! (And amazingly, this message is rejected as "You have included content that is not permitted" when I wrote "c all girls in D ubai", until I added the spaces!) (The word in the title is a small metal item used to join pieces of wood together, which can also be used as a euphemism for something couples do.)

I have a file on my Mac of a slightly unusual type. Let's say it's an "XYZ" file. Maybe I downloaded it from somewhere. I don't have any programs on my Mac that know about XYZ files, so if I view it in Finder is is shown with a plain icon and a generic description e.g. "Document". If I check its type, it seems that macOS has allocated it a "dyn.*" UTI: % mdls -name kMDItemContentType ~/foo.xyz kMDItemContentType = "dyn.ah62d4rv4ge81u8p4" I do have an app on my iPad that knows about XYZ files. The app has a UTImportedTypeDeclarations entry for .xyz in its Info.plist. I transfer the file to my iPad using AirDrop. Annoyingly, the iPad does not offer to open the file with the appropriate app. It seems to me that the iPad has blindly trusted the dyn.* UTI that macOS allocated for the file, and which presumably has been sent by AirDrop. It has not used the filename extension mapping from its app's Info.plist to determine that the file is an XYZ file. That may be considered a bug in iOS but that's not my question... My question is: is there anything that I can do on my Mac to tell it that this file foo.xyz is of type UTI com.example.xyz ? I was expecting to find either an md... command to modify the metadata, including the UTI, for a file, or some way to do this by setting an extended attribute. I have not yet found either. Any ideas anyone?

Dear Experts, Where is the best place to persist an App Attest key id? The docs ( https://developer.apple.com/documentation/devicecheck/establishing_your_app_s_integrity ) say “Record the identifier in persistent storage — for example, by writing it to a file”. That is what I have done, but I have encountered a problem. If a user gets a new device and restores a backup of an old device onto it, the new device will try to use the key id from the old device - which is of course wrong. One solution is to detect the error when the invalid key is used and to generate a new one. Is that the best approach? I am wondering if there is some part of the filesystem that does not survive the backup/restore process, but is otherwise persistent? It should be more persistent than a cache file. (Also looking at the docs again I now see that I am supposed to store distinct keys for each “user”. What is meant by “user” in this case?) Thanks.

Dear Experts, I have been looking at the documentation for system colours at https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/ https://developer.apple.com/documentation/uikit/uicolor/standard_colors/ https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors It's all reasonably clear... until I actually look at some UIKit screens and try to work out which colour is being used where. For example, what colour is the background of a navigation bar? It does not seem to be one of the standard colours. Attached is a screenshot from "UIKit Lab", which is a free UIKit catalogue/demo app. Scrolling through its list of standard colours, none of them seems to match the background of the navigation bar. It lies somewhere between systemBackground and secondarySystemBackground. Is this perhaps because the base colour has been modified by a material effect, or something? Thanks, Phil.

I’ve just tried to reply to a post and I get an “unauthorized” error page back. I’m logged in. I’m posting from an iPad, which is unusual, I normally use my Mac. This post is in part to see if I can post at all, or whether it was just that one reply that is. not working.

Dear Experts, If a user with an older device tries to download an app, and the current version of the app requires an iOS version which their device does not support, the App Store will offer them an older most-recent-compatible version instead. I've just had an enquiry from a user of my app for whom this has not worked. Specifically he has an iPad 2. He foolishly deleted my app from the device, and now the App Store will not let him re-install it. Does anyone know why this may be? Is it simply that this App Store feature does not work for devices as old as the iPad 2? Thanks.

Dear Experts, We are required to remove our NSFilePresenters from the NSFileCoordinator when the app goes to the background and re-add them when it returns to the foreground. Does this mean that when we foreground, we need to manually check if our files have been modified, deleted, or moved in the meantime? Or is there some mechanism in NSFilePresenter/NSFileCoordinator that will report any such changes to us? Detecting that a file has been modified or deleted is not difficult, but I don't think it's possible to detect that it has moved. Changes to directories are also difficult. Any advice? What does UIDocument do in this case?

Dear Experts, Should I use NSFileCoordinator coordinateWritingItemAtURL: around a call to NSFileManager trashItemAtURL: ? What options should I pass - NSFileCoordinatorWritingForDeleting, or ...ForMoving, or something else? I've attempted various combinations. If I don't use the NSFileCoordinator, then the change is not reflected in the Files app (open alongside my test app in iPad split screen mode). All attempts using NSFileCoordinator result in a deadlock inside trashItemAtURL - it is stuck waiting for a semaphore. I do have a FilePresenter for this file, but I am passing it to the NSFileCoordinator's init so that should not lead to deadlock. I believe I am doing everything on the main thread. The files are local, in the app's Documents directory. Any ideas anyone?

Dear All, Does anyone have any suggestions for an iPad text editor app that is well-behaved with respect to NSFileCoordinator / NSFilePresenter / UIDocument etc.? Specifically, I'd like something that I can run in iPad split screen mode alongside my test app. I'd like to be able to make changes to files using the text editor and see my test app pick them up, and vice-versa. I am currently trying an app called "Quick Text" which mostly works but it doesn't seem to pick up changes that I make in my test app unless I close and re-open the file at its end. I'm also soon going to reach its limit of "10 edits per week"! I have a couple of others to try, but maybe someone here has a suggestion?

Dear Experts, NSCoordinatedFile's coordinatedRead and coordinatedWrite methods supply a possibly-modified path to the accessor block. (I think it is only modified if there are concurrent accesses, so none of this is easy to test.) If I enumerate the contents of a directory inside a coordinatedRead on the directory, the paths that I get for the directory entries will include this possibly-modified parent path. (Unless maybe NSFileManager's enumeration methods have some magic to avoid that.) Is it OK for me to keep these "special" pathnames beyond the end of the coordinatedRead? If not, perhaps I need to get only the leafname from the directory enumeration and append that to the original directory path. Thoughts anyone?

Dear Experts, Is there a way to limit an NSMetadataQuery to one iCloud container, in an app with more than one? It seems to me that setting the scope to NSMetadataQueryUbiquitousDocumentsScope will probably return either the contents of the first (default) container, or all containers Is there something I can put in the predicate? Maybe I have to try to match URLs that start-with the container's own URL?

I believe that if I rename a file, I'm supposed to do that inside a coordinated write on the parent directory - right? So say I have a file /path/to/folder/f1 and I want to rename it (in the same directory) as /path/to/folder/f2. I do a coordinated write (with the forMoving option) on the directory /path/to/folder. That passes me a possibly different path to the directory, right? Say I get /path/to/different. Question: what rename should I actually do? Do I need to construct from and to paths based on the different path that is passed to the accessor? I.e. do I rename from /path/to/folder/f1 to /path/to/folder/f2 or rename from /path/to/different/f1 to /path/to/different/f2 or some other combination? Do NSFileManager's renaming methods do anything special in this regard? Can I use e.g. std::filesystem::rename()? I am interested in both local documents that are visible e.g. in the Files app, and iCloud Drive documents, if that makes any difference. Thanks!