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.

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

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.

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

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.

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.

Please file your own feedback report if you are hitting this problem (error -9,808) in the iOS 18 betas (feel free to reference FB13825638), as the more feedback received, the more likely Apple will be to fix the problem. If the appearance is that only a handful of users are affected, it will not be prioritized among the myriad of other problems that likely exist.

Confirming this is still regressed in iOS 18.0 beta 5 (22A5326f)! This is extremely concerning, as it is starting to appear that this regression is not going to be fixed.

Problem remains on iOS 18 beta 4 v2 (22A5316k). No change.

Problem remains on iOS 18 beta 4 v2 (22A5316k). No change.

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

Still occurs on iOS 18.0 beta 3 (22A5307f).

I see the same thing on macOS 15 beta 2 and I am also curious to know what can be done to fix this. References: https://developer.apple.com/documentation/uikit/uicommandtagshare?language=objc https://www.mattmoriarity.com/2019-10-18-share-menus-with-mac-catalyst/

@Frameworks Engineer Could you explain how UIKit presents the browser UI in front of my own custom view? Since the problem is not resolved in beta 2, I am looking for ways to work around it myself. The browser UI doesn't appear to be presented as a normal view controller. I suspected that it was added as a subview of the UIDocumentViewController's view, but that does not appear to be the case, either. I tried stopping in Xcode during a transition where the browser UI was visible and inspecting the view hierarchy in the Xcode view debugger, but this offered no clues. From what I saw there, I would expect my UI to be onscreen. Also, while trying to inspect state in the Xcode view debugger, the app managed to advance so that the browser was no longer shown on the device's screen. Perhaps this indicates what I'm seeing is some transitional animation captured in a CATransaction or something like that?

Problem remains in iOS 18.0 beta 2 (22A5297f). No change.