As you said, behavior is still regressed in iOS 18.0 beta 5 (22A5326f)! Added more comments in the thread linked by DTS above about the similar problem that occurred in iOS 17.0 betas.

Still broken in iOS 18.0 beta 6 (22A5338b)! This regression ought to be fixed as it was in 17.0. I appreciate that there may be a workaround, but my mail server is remote and I think it's unacceptable to require disturbing a longstanding mail server configuration (there is high risk of breakage) in order to make this work. Especially when macOS does the right thing. iOS should be consistent.

Still broken in iOS 18.0 beta 6 (22A5338b)! Haven't been able to use mail on my iPhone since WWDC :(

Sadly, this regression has shipped in iOS 18.0 (22A3354). I am not optimistic that we will see a fix going forward. The unfortunate reality of the way things work in Apple software engineering is that problems get deprioritized into oblivion unless users are clamoring for a fix. Regressions are prioritized, but once a regression has shipped and (almost) nobody complains, then the chances of it ever being fixed are greatly reduced, especially if there is a workaround, however cumbersome it is. With the exception of security issues, Engineering’s focus is primarily on new hardware support, “tentpole” features, and high-profile regressions resulting from changes driven be those things. It seems like there are never enough engineers to fix low-priority longstanding issues. I had really hoped to see more feedback from others on this regression, but I guess it must be a minority configuration. I really do not look forward to disturbing my longstanding mail server configuration, which will risk breaking e-mail on my Mac, the only way I can access my e-mail at this point. As I’m away from home until the end of the month, I won’t risk messing with it until then.

Sadly, this regression has shipped in iOS 18.0 (22A3354). I am not optimistic that we will see a fix going forward. :(

As of iOS 18.0.1, this issue remains unresolved. I've ultimately had to switch to a certificate from Let's Encrypt, as I can't wait forever for my e-mail to be accessible from my iOS devices. While this meets my current needs, it requires more maintenance than my previous setup, which had been stable for years. I noticed that this issue sparked a discussion on Hacker News a while back (https://news.ycombinator.com/item?id=41583689), where many people chimed in debating the pros and cons of running a server with a self-signed certificate, using an internal CA, a public CA like Let's Encrypt, or other solutions. However, this largely missed the point: This is a regression in iOS 18+. macOS 15+ still handles this correctly, suggesting the change was an unintended regression rather than a deliberate policy shift. Users shouldn't have to disrupt their stable, working configurations without good reason. While this configuration might only impact a minority, it’s crucial to highlight such issues. Apple’s focus is understandably on the majority, but raising these concerns can sometimes lead to resolutions.

I'm observing what appears to be the same or similar problem on iOS 18.3-18.3.2 with my own apps (WOZNIAC-1 and WOZNIAC-68). I don't see the problem when running under the 18.3 simulator—only on device. Filed: FB16862332 iOS 18.3 REGRESSION: UIDocumentViewController: Placeholder icon displayed instead of document icon in share menu item of document title menu When the problem occurs, I see the following error in the logs (a1vm is my file type's extension): Error returned from iconservicesagent image request: <ISTagIcon: 0x30299c040> Tag: a1vm, Class: public.filename-extension, Base type: public.item - <ISImageDescriptor: 0x300dd5860> - (37.00, 48.00)@3x v:40000 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AE3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request} Here is the expected behavior from the 18.2 simulator: Here is the on-device behavior from 18.3.2:

Correction: The app does not provide a custom document icon, but relies on UIKit to display the standard generic document icon with app icon overlaid (as on macOS in the sharing menu and Finder, or iOS Files app). As mentioned, this worked previously and is a regression in iOS ≤ 18.3

Forgot there was a previous thread discussing this over here: https://developer.apple.com/forums/thread/773760?answerId=829173022#829173022

I've created a separate thread for my similar report, which does not involve use of QLThumbnailGenerator (though similar error messages occur, so these problems seem likely related): https://developer.apple.com/forums/thread/786346 The problem I reported remains unresolved as of iOS 18.5: FB16862332 (iOS 18.3 REGRESSION: UIDocumentViewController: Placeholder icon displayed instead of document icon in share menu item of document title menu)

I've attached a sample project to my feedback report (FB16862332) that demonstrates the problem with Xcode 16.4 on iOS 18.5. This is just a minimally-modified version of the Document App project template from Xcode 16.4. Modifications are to provide an app icon and export a custom file type. diff --git a/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/AppIcon1024x1024.png b/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/AppIcon1024x1024.png new file mode 100644 index 0000000..0b96db4 Binary files /dev/null and b/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/AppIcon1024x1024.png differ diff --git a/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/Contents.json b/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/Contents.json index 2305880..b5305cf 100644 --- a/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/Contents.json +++ b/TestDocumentAppShareIcon/Assets.xcassets/AppIcon.appiconset/Contents.json @@ -1,6 +1,7 @@ { "images" : [ { + "filename" : "AppIcon1024x1024.png", "idiom" : "universal", "platform" : "ios", "size" : "1024x1024" diff --git a/TestDocumentAppShareIcon/Info.plist b/TestDocumentAppShareIcon/Info.plist index 48e3639..f7217d0 100644 --- a/TestDocumentAppShareIcon/Info.plist +++ b/TestDocumentAppShareIcon/Info.plist @@ -7,9 +7,11 @@ <dict> <key>CFBundleTypeRole</key> <string>Editor</string> + <key>LSHandlerRank</key> + <string>Owner</string> <key>LSItemContentTypes</key> <array> - <string>com.example.plain-text</string> + <string>com.example.exampletext</string> </array> <key>UIDocumentClass</key> <string>Document</string> @@ -32,17 +34,18 @@ </array> </dict> </dict> - <key>UTImportedTypeDeclarations</key> + <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> - <string>public.plain-text</string> + <string>public.content</string> + <string>public.data</string> </array> <key>UTTypeDescription</key> <string>Example Text</string> <key>UTTypeIdentifier</key> - <string>com.example.plain-text</string> + <string>com.example.exampletext</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> The following error messages are emitted when tapping the document title menu, when the placeholder icon is displayed: LPFileMetadataProviderSpecialization failed to retrieve a thumbnail from QuickLookThumbnailing (Error Domain=QLThumbnailErrorDomain Code=0 "Could not generate a thumbnail" UserInfo={NSUnderlyingError=0x10db4d800 {Error Domain=QLThumbnailErrorDomain Code=102 "(null)" UserInfo={NSUnderlyingError=0x10db4d860 {Error Domain=GSLibraryErrorDomain Code=3 "Generation not found" UserInfo={NSDescription=Generation not found}}}}}) Error returned from iconservicesagent image request: <ISTagIcon: 0x10db23500> Tag: exampletext, Class: public.filename-extension, Base type: public.item - <ISImageDescriptor: 0x10dadcaa0> - (37.00, 48.00)@3x v:40000 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AE3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request} Error returned from iconservicesagent image request: <ISTagIcon: 0x10dbe0400> Tag: exampletext, Class: public.filename-extension, Base type: public.item - <ISImageDescriptor: 0x10dadca00> - (37.00, 48.00)@3x v:40000 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: 0D3223D0-9AE3-3B19-A081-ACACE55691B7 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request} Error returned from iconservicesagent image request: <ISTypeIcon: 0x10daf1e60>,Type: com.example.exampletext - <ISImageDescriptor: 0x10dadd220> - (40.00, 40.00)@3x v:0 l:5 a:0:0:0:0 t:() b:0 s:2 ps:0 digest: E988236A-DCCF-30CB-83D0-D901CB1A5499 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request} It's worth noting that Apple's UIDocumentController-based apps like Pages and Numbers use dynamically-generated thumbnail icons, so that's presumably why the problem is not observed in those apps.

Problem still occurs on macOS 15.5 (24F74). I've received no updates from Apple in FB13819800 since filing this a year ago with sample project that reproduces the problem. Could mean they're fixing it in Next Major OS, but we really should have a fix in macOS 15.x at least, preferably 13.x+ in my case. For the record, here's the log up to the first exception on macOS 15.5: Save: timed out loading URL *** Assertion failure in -[NSSavePanel setNameFieldStringValue:], NSSavePanel.m:1347 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: aString != nil' *** First throw call stack: ( 0 CoreFoundation 0x0000000195f32ca0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x00000001959f6b90 objc_exception_throw + 88 2 Foundation 0x0000000197541a78 -[NSCalendarDate initWithCoder:] + 0 3 AppKit 0x000000019aaedd90 -[NSSavePanel setNameFieldStringValue:] + 560 4 ShareKit 0x00000001c8953ce0 -[SHKSaveToFilesSharingService saveFileURL:completion:] + 116 5 ShareKit 0x00000001c89542b4 -[SHKSaveToFilesSharingService save:completion:] + 80 6 ShareKit 0x00000001c8954508 __49-[SHKSaveToFilesSharingService performWithItems:]_block_invoke.46 + 60 7 ShareKit 0x00000001c8919778 -[SHKSharingService _runActionBlockWithItems:completion:] + 144 8 ShareKit 0x00000001c891c8f8 -[SHKSharingService performCustomServiceWithItems:] + 348 9 ShareKit 0x00000001c891c6e8 -[SHKSharingService performWithItems:] + 2504 10 ShareKit 0x00000001c8954408 -[SHKSaveToFilesSharingService performWithItems:] + 296 11 ShareKit 0x00000001c891bcfc -[SHKSharingService performWithItems:completion:] + 64 12 ShareKit 0x00000001c892db50 -[SHKSharingServicePicker _performSharingService:] + 912 13 ShareKit 0x00000001c892dc64 -[SHKSharingServicePicker _handleItemsReady] + 76 14 ShareKit 0x00000001c8931c98 __55-[SHKSharingServicePicker _performItemLoadsIfNecessary]_block_invoke + 32 15 ShareKit 0x00000001c892a490 -[SHKSharingServicePicker _loadSendCopyRepresentationIfNecessaryWithCompletionHandler:] + 180 16 ShareKit 0x00000001c8931c3c -[SHKSharingServicePicker _performItemLoadsIfNecessary] + 128 17 ShareKit 0x00000001c8931b74 -[SHKSharingServicePicker _performSelectedService] + 1176 18 ShareKit 0x00000001c89356e8 -[SHKSharingServicePicker _performActionWithIdentifier:] + 356 19 ShareKit 0x00000001c8955374 __65-[SHKShareSheetRemoteViewController performActionWithIdentifier:]_block_invoke + 56 20 libdispatch.dylib 0x000000010342c514 _dispatch_call_block_and_release + 32 21 libdispatch.dylib 0x00000001034492dc _dispatch_client_callout + 16 22 libdispatch.dylib 0x000000010346cc94 _dispatch_main_queue_drain.cold.5 + 900 23 libdispatch.dylib 0x000000010343dd98 _dispatch_main_queue_drain + 180 24 libdispatch.dylib 0x000000010343dcd4 _dispatch_main_queue_callback_4CF + 44 25 CoreFoundation 0x0000000195effda4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 26 CoreFoundation 0x0000000195ec0a9c __CFRunLoopRun + 1980 27 CoreFoundation 0x0000000195ebfc58 CFRunLoopRunSpecific + 572 28 HIToolbox 0x00000001a195427c RunCurrentEventLoopInMode + 324 29 HIToolbox 0x00000001a19574e8 ReceiveNextEventCommon + 676 30 HIToolbox 0x00000001a1ae2484 _BlockUntilNextEventMatchingListInModeWithFilter + 76 31 AppKit 0x0000000199de7ab4 _DPSNextEvent + 684 32 AppKit 0x000000019a7865b0 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 33 AppKit 0x0000000199ddac64 -[NSApplication run] + 480 34 AppKit 0x0000000199db135c NSApplicationMain + 880 35 AppKit 0x0000000199ffdcf4 +[NSWindow _savedFrameFromString:] + 0 36 UIKitMacHelper 0x00000001b13e4164 UINSApplicationMain + 976 37 UIKitCore 0x00000001c9a57c9c UIApplicationMain + 148 38 MobileRC6502.debug.dylib 0x0000000103620590 __debug_main_executable_dylib_entry_point + 188 39 dyld 0x0000000195a36b98 start + 6076 )

Really not a great experience having your app crash on launch with the first build under Xcode 26 due to longstanding supported functionality that you relied upon being removed without notice. At a minimum, if this functionality is removed, I would expect Xcode to include a conversion tool that would generate the corresponding code (in Objective-C) from an existing root menu within a storyboard. Even AI (I asked Google's Gemini, as I'm not yet in a position to install macOS 26 to enable the AI features in Xcode) admits that conversion is a difficult, error-prone task and demurs when asked to do it. Fixing things that are broken by the WWDC beta with no added value to my app (in fact, only higher development/maintenance cost) is not how I envisioned spending my WWDC week. Really disappointed by this.

The weird thing is, this only seems to occur when running under iOS 26 Simulator. The app built with Xcode 26 actually launches without hitting this issue on the host Mac (macOS 15.5) and a real iPhone (12 Pro) running iOS 26. Why is the simulator's behavior not aligned with the behavior of real devices? I normally test on real hardware, so it's only by chance that I happened to notice this. The lack of consistency here doesn't seem great, but if inconsistent on-device behavior is the only way I can test my app, then so be it. Edit: Spoke too soon. I didn't hit the exception until hitting a key on the onscreen keyboard under iOS 26. On macOS 15.5, I'm still able to use the rebuilt app, but I expect I would hit the problem on macOS 26 (will need to test).

Submited FB17978212 (iOS 26 beta: UIResponder inputAccessoryView no longer integrates seamlessly with system keyboard): Prior to iOS 26, it was possible to design an inputAccessoryView(Controller) that would integrate seamlessly with the system keyboard, by which I mean appearing as a natural extension of the system keyboard. For example, using CYRKeyboardButton https://github.com/tmcintos/CYRKeyboardButton. To date, I have successfully used this to provide an enhanced numeric key row within my apps, which is a distinguishing feature of these apps. It took a lot of engineering and testing effort to perfect this design. However, with iOS 26 the design is completely broken due to the system keyboard UI change, which places a margin with edge and rounded corners above the top row of the system keyboard. This makes it impossible to display an inputAccessoryView seamlessly along the top of the system keyboard (see attached screenshots showing previous and current app behavior after rebuilding with Xcode 26 and running on iOS 26 with no modifications to this functionality). This sort of UI change feels reckless—breaking existing app designs without adding any significant value to the user experience—and forces developers to waste time on rewriting their debugged, stable apps, likely creating more bugs instead of focusing on delivering the bug fixes and enhancements that they had planned.