@bryan1anderson I don't think you can. If your dataset is large enough (like my example), you'll always get hangs. It looks to me like Query/Predicate is the issue here, they seem to run everything on the Swift side rather than being transformed into SQL queries that run directly on the underlying SQL database. On the example that I posted and that @DTS Engineer confirmed, the SQL part runs really fast, but the overall fetch is slow. I'd love for Apple to give this more attention, because if having a big dataset is a deal breaker, nobody -unless you're 100% sure your data will always be very small- should use Swift Data. Imagine if you build a very complex app using Swift Data and your dataset keeps growing, you'll hit a point where you need to re-write the model layer using Core Data, kinda insane if you ask me.

This is still an issue on iOS 26.2.

@DTS Engineer Do you know if there's any progress on a fix for it or if there's any workaround? I tried injecting custom CSS, but that breaks many websites, and I can't be adding custom code for every single website out there 🤪 The bottom safe area seems to work as expected, the problem is just at the top with the navigation bar + top safe area. Here's a quick sample code that can be pasted anywhere to run and observe the issue on three different websites: import WebKit import SwiftUI @main struct WebViewSafeAreaApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { let urls: [URL] = [ URL(string: "https://mastodon.social")!, URL(string: "https://substack.com")!, URL(string: "https://apple.com")! ] @State private var selection: URL? var body: some View { NavigationSplitView { List(selection: $selection) { ForEach(urls, id: \.absoluteString) { url in Text(url.absoluteString).tag(url) } } .navigationTitle("Sidebar") .navigationBarTitleDisplayMode(.inline) } detail: { if let selection { WebView(url: selection) .navigationTitle("Detail") .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .bottomBar) { Button("Bottom safe area works!", action: {}) } } } else { Text("No URL selected") } } } } This is on iOS 26.2, using Xcode 26.2.

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...