As of iOS 26.1, Safari and WebKit views have an issue when rendering the <details> html tag. The disclosure-closed icon / character appears as an emoji arrow ▶️ instead of the unicode character ▸ (U+25B8 - Black Right-Pointing Small Triangle) For example: <details> <summary>Summary</summary> <p>Additional details....</p> </details> This wasn't the case in iOS 26.0 / iOS 18. From what I can observe it seems ▶ (U+25B6 - Black Right-Pointing Triangle) may be used in iOS 26.1 which renders as the emoji ▶️ on iOS (at least as far back as iOS 18). The only workaround I found for the moment is to specify explicit CSS to revert back to using the ▸ (U+25B8 - Black Right-Pointing Small Triangle) details > summary { list-style-type: "▸ "; } details[open] > summary { list-style-type: "▾ "; } Is this expected? I've filed a feedback for this FB20997955. Thanks!

When using Xcode 15 beta 6 / iOS 17 beta 5, it appears modal presentation and dismissal callbacks are sometimes not getting called. This is noticeable in our test suite where we artificially speed up animations via setting a high window layer speed (window.layer.speed = 100). Example: // Test results: // - Xcode15 beta 1-6: ❌ fails // - Xcode14.3.1: ✅ passes func test_modalPresentation_withFastAnimations() throws { // Given let root = try findActiveWindowRootViewController() let presentation = expectation(description: "Modal Presented") let dismissal = expectation(description: "Modal Dismissed") let modal = UIViewController() // When // ---- // updating layer speed on iOS 17.0 beta results // in presentation / dismissal callbacks getting omitted // subsequently failing tests due to unfulfilled expectations root.view.window?.layer.speed = 100 // ---- root.present(modal, animated: true) { presentation.fulfill() modal.dismiss(animated: true) { dismissal.fulfill() } } // Then wait(for: [presentation, dismissal], timeout: 4.0) } Context: We have a large number of UI tests and resort to increasing the layer speed to speed up the test runtime. Additional Notes: This seems to not affect .fullScreen modal presentation styles Similar issues were noticed with some animation callbacks getting omitted This has been noticed since Xcode 15 / iOS 17 beta 1 Feedback + sample project FB12362774 Is this an issue or expected behaviour going forward? Thanks!

Overview The UINavigationController / UINavigationBar title text no longer appears when updating a view controller's title property programatically. Example Given a view controller that is hosted within a UINavigationController: final class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() // start out with no title } private func updateTitle() { // update the title later on ... title = "Hello" } } In this case the title label remains blank after calling updateTitle() instead of updating to "Hello!". Details This only happens if the title starts out as nil or empty string Triggering a layout (e.g. rotating the screen) will restore the title Manually calling navigationController?.navigationBar.setNeedsLayout() restores the title Inspecting the view hierarchy, it appears the UILabel within the navigation bar has an alpha of 0.0 which is why it appears blank even after setting the title, it's not till after triggering a layout the alpha is reset to 1.0 (lldb) po navigationController?.navigationBar.perform(Selector("recursiveDescription")) ... <_UINavigationBarTitleControl: 0x7f84f5f11560; frame = (172.333 10; 45.3333 23); layer = <CALayer: 0x6000039e89a0>>   | <UILabel: 0x7f84f5f12000; frame = (0 0; 45.3333 23); text = 'Hello'; alpha = 0; userInteractionEnabled = NO; backgroundColor = UIExtendedGrayColorSpace 0 0; layer = <_UILabelLayer: 0x600001ab4410>>    | <UIView: 0x7f84d5f0fbc0; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = <CALayer: 0x6000039d7780>> Environment This only occurs when building with Xcode 14 beta 6 (14A5294g) and running on iOS 16 beta. Notes I was curious if anyone else encountered this? We initially missed this as many of our view controller had some default titles set but there were a few where titles get set asynchronously after viewDidLoad which surfaced this issue. I wonder if some of the changes related to SwiftUI listed in the release notes may have accidentally changed the behaviour: By default, a navigation bar only renders if it has content to display. If a navigation bar has no title, toolbar items, or search content, it’s automatically hidden. Use the navigationBarHidden(_:) or the new .toolbar(.visible) modifier to explicitly show an empty navigation bar. (84996257) I've filed a feedback FB11379313 with a sample project that reproduces this issue. Thanks

Overview We've noticed in iOS 15 beta the webView.scrollView.indicatorStyle property is no longer respected or rather no longer persisted when set on non-opaque WKWebViews. For example: webView.isOpaque = false webView.backgroundColor = .darkGray webView.scrollView.indicatorStyle = .white Once the content loads, the indicator style is reset to .black, and continues to be reset as the content is scrolled. This results in cases where there isn't sufficient contrast between the web view background color and the scroll indicators. Background We have a few cases where we leverage WKWebViews to display web content within our app. The web content itself doesn't set a background color for its body explicitly, rather it relies on the native app to set the web view's background color in code. The same web content is displayed in different contexts / platforms where slightly different background colors may be applied. It's unclear if this method was the correct way to achieve this, however prior to iOS 15, the code snipped above allowed us to set a custom background color along with an appropriate scroll view indicator style. Notes I believe WKWebView attempts to set an appropriate scroll indicator style based on the (web) content color automatically, however doesn't seem to handle the scenario where the content doesn't explicitly have a color and the web view is non-opaque. I spotted there's a new webView.underPageBackgroundColor property, setting that sadly didn't help resolve this case. Is this an expected new behaviour or a bug? Is there a better way for us to handle this use case? I've filed a feedback with a sample project in case that is useful (FB9605511). Any feedback on this is appreciated. Many thanks!