NavigationSplitView does not properly show detail pages on macOS 15

This was release noted here: https://developer.apple.com/documentation/macos-release-notes/macos-15-release-notes (Search 127626852)

Behavior was changed because the composition is undefined on iOS and was undefined on macOS, but happened to work in some cases.

This change was made behind a link check, so hopefully you are only seeing this when compiling against the newest Sequoia toolchains.

View-destination links (e.g. NavigationLinks that take a View as their destination) and value-destination links (e.g. NavigationLinks that take a value argument) cannot be mixed.

By attaching an id to the link, you are wiring the link up to the Lists selection, and thus trying to drive navigation that way. The correct way to do this in releases including and prior to iOS 15 and macOS 18 is by switching over the selection in the NavigationSplitView's subsequent column:

NavigationSplitView {
  List(selection: $selection) {
    NavigationLink("Value-destination link", value: 5)
  }
} detail: {
  if let selection {
    SelectedDestination(selection)
  } else {
    ContentUnavailableView(...)
}

Thanks a lot for the explanation! I didn't see it in the release notes.

I have a related question: Before I start trying to hack something together, is there a recommended way to do this type of value navigation if you can select two completely unrelated types from the list, which in turn navigate to unrelated detail views?

In Cork, these are:

• PackageDetailView, which takes the BrewPackage type
• TapDetailView, which takes the BrewTap type

Until now, this was solved by using the incorrect behavior of defining the destination view inside the NavigationLink:

NavigationLink
{
    PackageDetailView(package: package)
        .id(package.id)
} label: {
    PackageListItem(packageItem: package)
}

NavigationLink
{
     TapDetailView(tap: tap)
         .id(tap.id)
} label: {
     Text(tap.name)
}

In this example, and in other examples I could find, only one type is used.

I ended up implementing a solution where I wrap the destinations in a hashable enum like this:

enum NavigationTargetMainWindow: Hashable
{
    case package(BrewPackage)
    case tap(BrewTap)
}

And then navigate to them using the value like this:

NavigationLink(value: NavigationTargetMainWindow.tap(tap))
{
    Text(tap.name)
    
    if tap.isBeingModified
    {
        Text(tap.name)
    }
}

This still didn't work properly, so I had to move the navigation selection variable out of my global AppState and into a local @State variable; only then I stopped getting the message "Publishing changes from within view updates is not allowed, this will cause undefined behavior."

Another Issue Again

Now I'm however running into another issue: I have a .task on the detail view that's supposed to load additional data. This .task only gets triggered on the first load of the detail view, and never again, so the detail retains the stale data. I suppose SwiftUI is trying to be clever and not reconstruct the entire view?

I tried using .task(id: package.id), and this does fire the task, but there's a split second where the old view is still visible, which isn't desirable:

https://streamable.com/3ucoy9