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 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 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?

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?

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?