Seems this is still happening in the 26.2 beta as well.

Still happening in the live release of Xcode 26.

Seeing this crash in beta 8 (Xcode beta 7). Symbol not found: _$s7SwiftUI17EnvironmentValuesV33_navigationIndicatorVisibilityABIAA0G0OvpMV Referenced from: <35BAAD44-14F4-3B6C-8568-3E8B57A526ED> My call site: var allMerchantsSection: some View { Section { ForEach(model.paginatedMerchants.items) { merchant in NavigationLink(value: MerchantDestination.merchant(merchant)) { CardCell( image: .remote(url: merchant.info.bannerUrl), text: merchant.info.merchantName, description: nil, chipText: nil ) .navigationLinkIndicatorVisibility(.hidden) } .listRowBackground(Color.backgroundPrimary) .listRowSeparator(.hidden) .onAppear { if model.canLoadMore, merchant == model.paginatedMerchants.items.last { model.paginatedMerchants.currentPage += 1 } } } } header: { Text("All Merchants") } } made a feedback report: FB20108722

So I had a similar problem. I had a calendar-like view where the latest data is at the bottom. By default, it had 12 items in a LazyVGrid (3 rows of 4 items). You could tap "show more" to expand the size of the view to 600 in height, and also make it scrollable with the top view triggering a fetch of the next page of results. The problem was, the act of resizing this view, and triggering the next page of results was causing the scroll view to jump to the top, rather than staying at the bottom. So essentially it would start loading all pages infinitely. .scrollPosition and the ScrollViewProxy do not seem to work, because at the time of hitting "show more" the bottom is already visible, so the act of changing the scroll position does nothing. The only workaround I found here was to add a delay long enough for the resize animation and for enough results to load to prevent another page load from triggering. Unfortunately, this was not at all reliable. The only fix I have found was to use .defaultScrollAnchor(.bottom) which seems to cause the scroll view to default to the bottom when it's being redrawn rather than to the top. But unfortunately, we are on iOS 16, so I can't use that modifier either.

It also happens if you use @Observable or @State for the source of your data. So its not an issue with ObservableObjects

It seems the bug is related to updating the source of the foreach while scrolling. The only workaround I have found so far is to pre-populate all of the possible pages before hand. But for an endless scroller that does not make much sense.

I can't believe Xcode 15.3 shipped in this state. This is probably the buggiest Xcode release yet.

Looks like the reason this happens is because the swift-format team created a COMMAND plugin. Instead of a BUILD plugin. If you right click on your package.swift file you should see an option in Xcode to run swift-format. I really want to use the official tooling with my projects. But time after time, it just seems like apple does not care about swift tooling. swift-format just seems to be a pain to work with. I can't even get it working with build phases. My script hits the line of code to trigger swift-format, but then nothing happens. Going to switch to SwiftLint

This isn't a built in feature, but I created an environment key called isSelected. The Environment is how most of the built in view modifiers work under the hood. struct SelectedEnvironmentKey: EnvironmentKey { static var defaultValue: Bool = false } extension EnvironmentKeys { var isSelected: Bool { get { self[SelectedEnvironmentKey.self] } set { self[SelectedEnvironmentKey.self] = newValue } } } then in the ForEach you can do: ForEach { myModel in RowView(model: myModel) .envrionment(\.isSelected, selection.contains(model)) } Then in your RowView struct RowView: View { @Environment(\.isSelected) private var isSelected var body: some View { // My views .background { if isSelected { return Color.blue } } } }

3:18 PM EST, seems to be fixed for me (the developer portal link), App Store still broken. XcodesApp and Xcodes CLI still seems to be broken, but I think thats an issue on their end.

Not sure if this would work. But you could try something like this: struct LoadingPreferenceKey: PreferenceKey { var defaultValue: Bool = false static func reduce(value: inout Self.Value, nextValue: () -> Self.Value) { value = nextValue() } } struct RootView: View { @State var loading: Bool = false var body: some View { ContentView() .fullScreenCover(isPresented: $loading) { MyLoadingView() } .onPreferenceChange(LoadingPreferenceKey.self) { isLoading in loading = true } } } struct ContentView: View { @State private var showingSheet = false var body: some View { Button("Sheet Open") { self.showingSheet.toggle() } .sheet(isPresented: $showingSheet) { SheetView() } } } struct SheetView: View { 　 @State var isLoading = false var body: some View { ZStack{ VStack{ Text("SheetView") Button("Submit Data"){ isLoading = true // Submitting now...... isLoading = false } } if isLoading { ZStack{ Color.white.opacity(0.5) .ignoresSafeArea() .frame(width: geometry.size.width, height: geometry.size.height) ProgressView() } } } .preference(LoadingPreferenceKey.self, isLoading) } }

I found a somewhat hacky workaround for this. You can "pre-render" the navigation bar customization so that it does not appear to pop in. This is not ideal though. Hopefully someone at apple fixes it. As it pretty much makes programmatic navigation in a mixed codebase impossible. let hostingController = UIHostingController(rootView: MyViewWithASearchBar()) hostingController.title = "My search page title" // pre-render the search bar let searchController = UISearchController() if #available(iOS 16.0, *) { hostingController.navigationItem.preferredSearchBarPlacement = .stacked } hostingController.navigationItem.searchController = searchController hostingController.navigationItem.hidesSearchBarWhenScrolling = false navigationController.pushViewController(hostingController, animated: true)

This is super frustrating. Happens in iOS 17 beta as well. simultaneousGesture is supposed to solve this issue. Made a radar for it: FB12683243

Can confirm this is happening to me as well on Xcode 14.3

is there a more dynamic way of doing this? adding a new extension on user defaults every time you have a new key isn't very scalable.