That's actually what navigation bars looked like back in iOS 12 so maybe your simulator is getting nostalgic. I also noticed in your sample code you are embedding a NavigationStack inside another which isn't recommended, but that isn't the cause of the problem. I would definitely file a feedback because there is no reason for the navigation bar to look like that just because of a map somewhere in the view hierarchy. However, there is some good news… this doesn't seem to be a problem in iOS 26, and most importantly, I have a fix and it's this: .toolbarBackground(.automatic, for: .navigationBar) // renamed to toolbarBackgroundVisibility in Xcode 26 What you were seeing was the background of the navigation bar being permanently visible, regardless of the scroll position. It seems like the map sort of forced this behaviour.

In iOS 26, UINavigationController has a new property called interactiveContentPopGestureRecognizer and is described as this: The interactive content pop gesture recognizes on the entire content area of the navigation controller in cases that are not covered by the interactive pop gesture recognizer and initiates an interactive pop. This property should only be used to set up failure requirements with it. So I believe now the pop gesture properties are defined as so: interactivePopGestureRecognizer is the swipe from the edge gesture interactiveContentPopGestureRecognizer is the swipe anywhere in the main content gesture So by disabling both gesture recognisers, you should be good to implement your custom swipe gestures. navigationController?.interactivePopGestureRecognizer?.isEnabled = false navigationController?.interactiveContentPopGestureRecognizer?.isEnabled = false

I don't know exactly what the Settings app uses internally, but using UICollectionView with a UICollectionViewCompositionalLayout.list layout in .sidebar style is the modern, recommended approach for creating lists with default styling and system backgrounds. Since Apple introduced modern collection views, they've recommended UICollectionView over UITableView for more complex layouts and advanced list styles. Check out Advances in UICollectionView, Lists in UICollectionView, and the official docs for more examples and code.

In your code, you've configured a URLRequest object but aren't using it anywhere. Currently, you're fetching data like this: URLSession.shared.dataTask(with: url) This performs a GET request to the specified URL. Instead, you should use the method that accepts a URLRequest: URLSession.shared.dataTask(with: request)

You should move the .confirmationDialog from the Button to the Menu as that's where it will be attached to/morph from. The reason the dialog (as well as other presentations) doesn't show either is because I don't think they are supported from within a Menu like that.

The issue is this part despite what the error message says: TextField("", text: c.strings[r][c]) The first quick point is that you are using c here as the environment object and the ForEach closure parameter, so Swift is getting confused and doesn't know which one you are referring to. I will be referencing the environment object property as controller. The second point is illustrated further by the example you gave. TextField("", text: $text) TextField expects to be passed a Binding<String> which is why you prepend the $ symbol to obtain one from a variable. However in your code, you are passing in controller.strings[r][c] which is just a regular String and not a binding, which is why the error occurs. To solve this, you need a way of getting a Binding<String> from your current String property. There are two ways of approaching this — pick whichever one you prefer. ‎ Use the Bindable property wrapper which facilitates creating bindings from the mutable properties of observable objects. var body: some View { @Bindable var controller = controller TextField("", text: $controller.strings[r][c]) } ‎ Manually create a Binding and pass that to the text field. TextField("", text: .init { controller.strings[r][c] } set: { controller.strings[r][c] = $0 })

I don't think there's anything wrong with the documentation. ‎ states that I can get the default content configuration of a UICollectionViewCell The documentation doesn't actually state this. UICollectionViewCell is just a generic cell type where you, as a developer, can customise its contents and layout. So while it does have a defaultBackgroundConfiguration() method, there is no specific default content configuration that can exist. What the documentation does say is this: For views like cells, headers, and footers, use their defaultContentConfiguration() to get a list content configuration that has preconfigured default styling. Alternatively, you can create a list content configuration from one of the system default styles. If you navigate to the defaultContentConfiguration() method, you will see that it is defined on UICollectionViewListCell. This is the type you use for creating standard cells in a list with list-specific features. If you aren't using this type of cell or want different default styling, then you can follow the alternative and use one of the static UIListContentConfiguration methods. So maybe the documentation can be clearer in specifying UICollectionViewListCell, but I think its inferred with all of the list types, detailed further in sample projects and other documentation pages, and also the fact that you are creating a list.

The new behaviour in iOS 26 is for labels in system menus to have the icon first then the title. The previous behaviour was a leading title and a trailing icon. According to your screenshots, "System App" shows the new iOS 26 behaviour and "Custom App" shows the older one. What iOS version is "Custom App" running on? If it is iOS 26, then make sure you are building new versions with Xcode 26 and also check to see if you've set the UIDesignRequiresCompatibility Info.plist key to YES (and change it to NO or just remove it). On your other point, there is very little customisation available in menus and the layout is handled by the system, so you can only set simple properties like title and icon.

What do you mean by "does not work"? I'll need more information such as the code you're using and the expected vs actual behaviour you are seeing. Also have a read of the documentation to see the usage and expected behaviour on both iOS and macOS. If you want a different behaviour or additional features, then submit an enhancement request.

Could you try using generics? public struct ViewProvider<Provider: ModuleProviding>: Equatable { let provider: Provider public init(provider: Provider, completion: @escaping () -> Void) { ... } } Since I don't have any other knowledge about the rest of your codebase, I can't be certain whether this will fit in or even work properly.

The problem here is that your data model is a class. The @State property wrapper is primarily designed to work with value types (like struct and enum). When you assign a new value to a @State variable, SwiftUI can see that the entire value has changed and re-renders the view. But with a class, the reference stays the same when you just change its properties, so SwiftUI doesn't notice and doesn't update the view. However, that doesn't mean you can't use classes at all. The Observation framework allows a class to expose properties that, when changed, will cause the view to update. So, you have two options: Change your data model to a struct. Add the @Observable macro to your data model.