I use a pre-compiled CAR file that has the pre-rendered Icon-Composer bitmaps stripped, so macOS 15 and older use the .icns file instead of the CAR assets. I did manage to solve this for both iOS and watchOS 26 similarly, but it's a lot more complex – I merged the pre-26 and 26 CAR files into a single CAR file so it includes both manually created, multi-resolution bitmaps for iOS 18 and watchOS 11 and the iOS/watchOS 26 iconstack-based icons. Unfortunately, Apple does not provide any good tooling for CAR files so it had to be done manually, but thankfully I'm highly familiar the CAR format and its internal formats (I've messed with its internals a lot since 2014), so it wasn't that bad.

For macOS I simply use an .icns file, and keep the Asset Catalog with only iconstack-based icons.

Considering macOS still suffers from bugs I reported back in 2014, I never expected anything. Maybe Apple shouldn't have completely dropped in-house QA if they can't handle 20K bug reports a day. Anyway, back on topic – requiring games to support running in windowed mode in arbitrary sizes and aspect ratios simply doesn't make sense. Games aren't apps, they aren't designed for multi-tasking, they're often designed for a very narrow range of aspect ratios. Despite having support for mice, keyboards, game controllers and a pen, the main and often only input method on an iPad is the touch screen, and games will often design their input systems around the assumptions that the app spans from one edge of the screen to another. My game app specifically is useless when you use it windowed, it assumes you're holding the iPad with both hands, and use your two thumbs to to control it. When the app is windowed, so simply can't reach at least half of the controls. Currently, the only "solution" is to "detect" the app running in windowed mode, pausing the game, and asking the user to put the app back into fullscreen, and that's terrible UX.

Almost two weeks with no response what so ever. What's even the point of a "Developer Preview" if nobody's ever going to respond to any feedback or questions developers have?

I also submitted feedback (FB18467555) for this issue. Sadly, considering the last time I submitted a feedback that got any response from Apple was early 2014, I doubt this will ever be addressed.

Unfortunately it seems like coordinateWritingItemAtURL:options:error:byAccessor: suffers from the same issue and calls, but coordinateReadingItemAtURL:options:error:byAccessor: does actually work. It's a bit annoying because it complicates both updating files and syncing multiple files (e.g. bundle-based formats), but it is something I can work around. It's very unfortunate that it's indeed a bug and not some API-misuse, because it seems to affect at least iOS 15 and up, and I'm targeting iOS 13-18. Thanks for your help!

Any update on this? I can't add iCloud support to my app without being able to safely download and sync files.

Note that I use a writing intent because I sometimes need to update some of these files, but using a reading intent instead does not solve the issue.

I first obtain the directory listing with NSMetadataQuery, which works fine. Once the query is done, I great an array of intents like this: for (NSMetadataItem *item in query.results) { NSURL *itemURL = [item valueForAttribute:NSMetadataItemURLKey]; if (![allowedExtensions containsObject:itemURL.pathExtension.lowercaseString]) { continue; } NSFileAccessIntent *intent = [NSFileAccessIntent writingIntentWithURL:itemURL options:0]; [intents addObject:intent]; } Then, after stoping the query and removing the notification observer for it, I create a coordinator with the intents array I created and use it: NSFileCoordinator *coordinator = [[NSFileCoordinator alloc] initWithFilePresenter:nil]; [coordinator coordinateAccessWithIntents:intents queue:queue byAccessor:^(NSError *error) { // This gets called with error = nil in Airplane Mode for (NSFileAccessIntent *intent in intents) { // Sometimes, the file at intent.URL does not exist! } }];

Long-press and Share seems to work for most users even with this conflict, although some still have this problem. However, if my app uses UIDocumentPickerViewController with my UTI type, it can't select any file if another app "snatched" the extension first. I can use UTTypeCreatePreferredIdentifierForTag to dynamically obtain the effective UTI for the extension, but then I have this problem where apps erroneously declare a single UTI with multiple, unrelated extensions, which UIDocumentPickerViewController to select files I don't even support. Even when I use the newer UTType API, I can't seem to get any UTType that works just for my file extension.

My app, which isn't particularly large, has been in review for almost 6 days with not sign of progress. That's almost 3 times more than "90% of the apps". Other people I asked about the review process also complained about exceptionally long review times. I'm under the impression that the estimate in this FAQ collection has no basis in reality.