No, my problem still occurs in iOS 26 Beta 9 (23A5336a): FB16862332 (iOS 18.3 REGRESSION: UIDocumentViewController: Placeholder icon displayed instead of document icon in share menu item of document title menu) Will continue to use https://developer.apple.com/forums/thread/786346 for follow-up on this problem. Sorry for creating confusion here.

I met with the UIKit team last week and discussed this briefly. They explained some of the challenges that led to this decision, and that they didn’t make it lightly. I might’ve been more receptive to this change had the messaging been better. For instance, if it were explicitly mentioned in a WWDC session or, ideally, at last year’s WWDC—a year before the removal of support. They thought it was mentioned in the release notes this year, but I haven’t found it.

Sorry for the lack of clarity here. It throws an exception during execution when -buildMenuWithBuilder: is invoked on the UIApplication if you have rebuilt with Xcode 26. When running an app built with Xcode 16 on iOS 26, I did not encounter this exception; I didn't check whether any warning was emitted in that case.

Thanks! Filed feedback (see below).

Thanks! Confirmed this works as you've described. That's a relief! I had perhaps naively expected UTM and macOS to just "do the right thing" here and automatically detected the active input devices, as in the host OS.

Yes, I believe there are really two bugs here: this one (which can be worked around as I described above) and the crash that occurs after working around this.

Yes, the backtrace is: *** 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: ... 2 Foundation 0x0000000197541a78 -[NSCalendarDate initWithCoder:] + 0 3 AppKit 0x000000019aaedd90 -[NSSavePanel setNameFieldStringValue:] + 560 ...

I moved discussion of my particular use case (which may or may not be related to this, though it seems likely) to a separate thread, here: https://developer.apple.com/forums/thread/786346

Actually, that thread originally tracked a potentially-related problem involving QLThumbnailGenerator. The problem I've reported is much simpler (doesn't involve QLThumbnailGenerator) and is trivial to reproduce.

It's a regression—Apple needs to fix it, so keep the pressure on them.

Closed FB13420491 as fixed in macOS 15.

Everything was fine through all the 17.x updates until I installed first iOS 18 beta, then the problem was back again. I haven't been able to access most of my e-mail from my iPhone since moving to the betas. I have an iPhone 14 Pro, so I'm unable to test the 18.1 beta to see if the problem is fixed there (though I kind of doubt that it is, otherwise they would've likely back-ported the fix to 18.0).

We went through this same problem with iOS 17, and it was an acknowledged regression fixed before the final release 17.0 release. I ended up wasting lots of time removing and re-adding my mail account, and anything else I could think of, with no success, until the problem was finally fixed by Apple in the iOS 17 beta 3 update (as mentioned in a post above).

Yep, the error text is: === Cannot Get Mail The mail server "[redacted]" is not responding. Verify that you have entered the correct account info in Mail settings. Unable to create a secure connection to the server ("bad certificate format" -9,808). === No problem accessing the same server from macOS 15 beta 4 or 15.1 beta.

Problem remains in iOS 18 beta 4 (22A5316j). No change.