@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!

Hey @DTS Engineer, thanks for your response! I do believe this should work as expected (no hang whatsoever) without the need for pagination. On UIKit + CoreData you don't need pagination, using an NSFetchedResultsController allows you to display as many items as you wish on a UITableView/UICollectionView without any hangs whatsoever. I've filed FB15507372 and put up the project for anyone to download and run here so it's easily reproducible: https://github.com/xmollv/SlowData

After more digging, it looks like List is doing the correct thing, but @Query seems to be loading all data up-front. I've enabled the SQL debug logging and I see the following when I tap on the All menu item: CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK CoreData: annotation: sql connection fetch time: 0.0025s CoreData: annotation: fetch using NSSQLiteStatement <0x60000622dd60> on entity 'Item' with sql text 'SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZISOPTIONA FROM ZITEM t0 ORDER BY t0.Z_PK' returned 15000 rows But then if I add a print statement on the init of what would be the row view of each List item, it only calls the init for as many times as rows fit on-screen. So, my final question is: If the fetch to the database is pretty much instant, and List only loads the cells that are visible on-screen, why there's such a massive hang? If instead of using @Query I simply pass 15_000 Items, there's no hang. But the fetch seems extremely fast, so I'm really confused at where's the problem. Gist with the code: https://gist.github.com/xmollv/e682ad6c22ac0bfd4b410e9fdb6db5c4

We're experiencing the same issue. Started like 4 hours ago and doesn't seem resolved yet. Not all builds fail, but the majority do.