SwiftUI Nested Scrollviews problem on macOS

I've found a workaround for the bug, although I hope it will soon be solved by Apple.

To my best understanding the underlying issue is that the mouse wheel scroll events are not forwarded from the inner horizontal scroll view to the outer vertical scroll view.

What makes it so frustrating is that there is the AppKit method exactly for that scenario: specifies whether the scroll events should be forwarded up the responder chain. It's called wantsForwardedScrollEvents and it's documented here in the Apple documentation. Even though the documentation says it's for "elastic scrolling", this stack overflow answer shows how it's equally useful for passing the events up the responder chain for all scrolling events.

So what we need is:

1. Make a NSView that overrides the wantsForwardedScrollEvents and returns true for the vertical scrolling axis so that the vertical scrolling events are passed from the inner horizontal scroll to the outer vertical scroll.
2. Insert this NSView into the SwiftUI view hierarchy between the horizontal scroll and the vertical scroll.

The second point is a little tricky, but thankfully the truly amazing SwiftUI Lab blog has a wonderful tutorial on how to do exactly that. Seriously, I cannot count how many times this blog has saved my sanity when working with SwiftUI.

So the final code can look like that:

// we need this workaround only for macOS
#if os(macOS) 

// this is the NSView that implements proper `wantsForwardedScrollEvents` method
final class VerticalScrollingFixHostingView<Content>: NSHostingView<Content> where Content: View {

  override func wantsForwardedScrollEvents(for axis: NSEvent.GestureAxis) -> Bool {
    return axis == .vertical
  }
}

// this is the SwiftUI wrapper for our NSView
struct VerticalScrollingFixViewRepresentable<Content>: NSViewRepresentable where Content: View {
  
  let content: Content
  
  func makeNSView(context: Context) -> NSHostingView<Content> {
    return VerticalScrollingFixHostingView<Content>(rootView: content)
  }

  func updateNSView(_ nsView: NSHostingView<Content>, context: Context) {}

}

// this is the SwiftUI wrapper that makes it easy to insert the view 
// into the existing SwiftUI view builders structure
struct VerticalScrollingFixWrapper<Content>: View where Content : View {

  let content: () -> Content
  
  init(@ViewBuilder content: @escaping () -> Content) {
    self.content = content
  }
  
  var body: some View {
    VerticalScrollingFixViewRepresentable(content: self.content())
  }
}
#endif

Having that structure ready, we can use it in your sample like this:

import SwiftUI

// just a helper to make using nicer by keeping #if os(macOS) in one place
extension View {
  @ViewBuilder func workaroundForVerticalScrollingBugInMacOS() -> some View {
    #if os(macOS)
    VerticalScrollingFixWrapper { self }
    #else
    self
    #endif
  }
}

struct ScrollViewProblem: View {
  
  var body: some View {
    ScrollView {
      HStack {
        Text("Scrolling Problem")
          .font(.largeTitle)
        Spacer()
      }.padding()
      
      ScrollRow().workaroundForVerticalScrollingBugInMacOS()
      ScrollRow().workaroundForVerticalScrollingBugInMacOS()
      ScrollRow().workaroundForVerticalScrollingBugInMacOS()
      ScrollRow().workaroundForVerticalScrollingBugInMacOS()
    }
  }
}

Verified on macOS 11.0.1 and Xcode 12.2.

[updated based on comment by @marshallino16]

You might encounter one SwiftUI issue after you've added the NSView into your view hierarchy. The inner views stop responding to the change in the state of the outer view.

Using the terms from sample code here: if there is a @State variable in ScrollViewProblem that is passed down to ScrollRow, the ScrollRow doesn't always recompute on that @State variable change.

This issue is mentioned in the "An Unpleasant Surprise" section of SwiftUI Lab blogpost.

Unfortunately, I've not found a direct workaround to make the @State propagation work again, so currently the best working solution I'm aware of (and been using myself) is to not pass the @State variable from the ScrollViewProblem to ScrollRow.

This means that whatever information you need to pass to ScrollRow, you must encapsulate it in the external object (view model, view store, whatever your architecture uses). Then you can pass this object to the ScrollRow and let the ScrollRow keep it and use it as either @State or @StateObject variable.