This is still an issue on iOS 26.1.

@DTS Engineer That's great to hear! I'll definitely be on the lookout for OS 26 betas to see if it gets fixed and I'll remove the workarounds that I've added. Do you know if the issue is WebKit related or SwiftUI related? Asking because if it's WebKit, it might be available on the WebKit bug tracker that's publicly available, and rather than needing to check on every beta, I could keep an eye on the bug ticket to see what's the progress! Either way, thanks again for looking into this! Can't wait for it go get fixed, it'll make my app looks so much better! 🤞

@DTS Engineer As requested, here's the Feedback: FB20169593. Thanks!

@DTS Engineer Here's a screenshot with .safeAreaPadding(.vertical, 100) applied to the WebView. As you can see, nothing changes. I've been playing with this, and I sort of got an idea. I could observe the scroll position of the WebView, and move the Dividers I showed on the original post as a workaround as needed (on the video I toggle them with a button just for show): But after having done that, what I really want (I think), is simply being able to remove the clipToBounds on the WebView. That way I could always position it inside the safe areas so the content is always accessible (and web content 'sticky' top/bottom is always reachable), but whenever the user scrolls, the content would flow below the navigation bars because it would bleed outside of the WebView since it's no longer clipped by the bounds. I've tried the scrollClipDisabled, but doesn't seem to change anything, any suggestions are much appreciated! Again, I'm using the VStack + Dividers combo because if I don't, the WebView fills the entire screen not respecting the SafeArea. If there's another way that's better that might help with the removal of the clipToBounds, I'm all ears! 🙏

Hello @DTS Engineer. I don't think that ScrollView works the same way. From my point of view, ScrollView correctly handles the safe area. The content on a ScrollView starts right below the safe area, where on the WebView it doesn't. Here's a quick example of what I mean. On the ScrollView, the content is always accessible. On the WebView, the top part is not. About the suggestions: safeAreaPadding(_:) doesn't seem to change anything when applied to the WebView. Modifying the CSS is not an option since I'm trying to load any webpage (building sort of a browser wrapper). Any more ideas? I do really want to have websites behave like they do on Safari (or on SFSafariViewController) where the website content starts below the safe area and moves under the bars as you scroll. But I can't figure out how to make WebView behave like those two.

This seems to have been fixed on iOS 26 beta 8. Now I can toggle properties and many times as I want and the List updates as expected.

This seems to still be broken on Xcode 26 beta 6 (17A5305f) and iOS 26 beta 7 (23A5326a). I've updated the Feedback too with this information.

@DTS Engineer This definitely looks like a regression. And yes, I've filed the following feedback: FB19629783. Thanks for looking into this! 🤞

Greg de J. found a solution. Turns out this only happens if you call some of the WKWebView APIs, see: https://mastodon.social/@quicheindustries/114590816761623008 He found out that the issue came from calling WKWebView.createPDF. In my case, I was using WKWebView.createWebArchiveData, which also triggers the issue. Until it's solved by Apple, the easiest fix is to compile out this code on the simulator using the #if !targetEnvironment(simulator) directive. Changing my code to this, let's the app run on the simulator without issues: #if !targetEnvironment(simulator) webView.createWebArchiveData { _ in } #endif

I'm facing the same issue, not it looks like I can't run the app on any simulator. Works fine if I run on device and from builds coming from Xcode Cloud, would love to know of a workaround so I can keep using the simulator 😭

@marcosatanaka I'm observing the same issue, it works fine on iOS but that code is never called on macOS. Did you figure out a solution or it's simply broken?

Just updated to Xcode 16.3 and indeed, the networking on the iOS 16.4 simulator is broken. Not sure if the suggested are enough, since it seems that the SDKs we use are also affected, and we can't change the settings for their internal URLSession usage...

This has started happening again today, we're observing builds queued for > 30 minutes right now. @Developer Tools Engineer

We started facing the same issue today. Builds are queued up for over 30 minutes and they run forever with no end. Our builds usually take ~12 minutes to complete, so I guess something's broken on Xcode Cloud. Hoping for a quick fix because we rely on it to ship updates! 🤞

Turns out, this was my own issue! I was passing the schema on both ModelConfigurations, when I should be passing a different Schema for each configuration, and then a Schema that contains everything to the ModelContainer init. I made such change, and now it works as expected, only the LTRLink appear on iCloud's console!