iOS 27 Beta 5: Button actions ignored inside horizontal SwiftUI ScrollView (minimal repro)

Question

Created 1w

Replies 4

Boosts 2

Participants 4

On iOS/iPadOS 27 Beta 5 (24A5408d), I can consistently reproduce SwiftUI Button actions being ignored when the buttons are placed inside a horizontal ScrollView near the top of a view. This occurs on physical iPhone and iPad devices and on an iPhone 16 Simulator. Equivalent UI was reliable on the preceding beta.

Minimal shape:

struct ContentView: View {
    @State private var selection = "All"

    var body: some View {
        NavigationStack {
            VStack(spacing: 0) {
                ScrollView(.horizontal, showsIndicators: false) {
                    HStack {
                        ForEach(["All", "Food", "Transport"], id: \.self) { item in
                            Button(item) {
                                selection = item
                            }
                            .padding()
                        }
                    }
                }

                Text("Selected: \(selection)")
                Button("Control below") { selection = "Control" }
                Spacer()
            }
            .navigationTitle("Touch Hit-Test Repro")
            .navigationBarTitleDisplayMode(.inline)
        }
    }
}

The standalone reproducer includes an XCUITest comparison. Results on the iOS 27 Beta 5 iPhone 16 Simulator:

Horizontal ScrollView: fails; the chip is reported as hittable but tap() does not invoke its action.
Remove .searchable: still fails.
Remove the sheet: still fails.
Remove only the horizontal ScrollView: passes.
Tap a normal button below the strip: passes.

Final result: 3 failed, 2 passed. This points to a Beta 5 hit-testing or gesture arbitration regression involving Button inside a horizontal ScrollView, rather than application state or a transparent overlay.

Feedback filed: FB24307724

Has anyone found a framework-level workaround that preserves both native button semantics and horizontal scrolling? Related historical reports include https://developer.apple.com/forums/thread/763436 and https://developer.apple.com/forums/thread/794212.

Answered by Laketauponz in 901947022

It appears Beta 6 has fixed the issue for me.

Answer 1

Laketauponz OP

1w

I’m seeing what appears to be the same regression on iOS 27 Beta 5 in a production SwiftUI app.

In my case the affected UI is a horizontal filter/action: ScrollView(.horizontal, showsIndicators: false) { HStack(spacing: 8) { groupMenu sortMenu templatesButton voiceButton } .padding(.horizontal, 16) .padding(.vertical, 8) }

The controls are a mixture of native SwiftUI Menu and Button views rather than one custom control implementation:

Group: Menu
Sort: Menu
Templates: Button
Voice: Button

On iOS 27 Beta 5 the controls render normally, but taps around the centre/upper portion of the controls are frequently ignored. Tapping toward the lower edge of the same visible control can trigger it.

The important part in my case is that multiple different control types in the same horizontal ScrollView exhibit the same behaviour. The actions themselves are working — when the tap is recognised, the menu opens or the button action runs normally.

The surrounding screen uses a normal NavigationStack with an inline navigation title and .searchable, but this report’s minimal reproduction is particularly useful because removing .searchable does not resolve the problem and removing the horizontal ScrollView does.

This makes the horizontal ScrollView / hit-testing or gesture arbitration regression described here a very strong match for what I’m seeing.

I’m currently testing an existing app build on a physical iPhone running iOS 27 Beta 5. The same UI was reliable before this beta. I’m holding off on introducing an application-level workaround for now because this appears to be a framework regression rather than an issue with the individual button actions.

I’d also be interested to know whether Apple has acknowledged FB24307724 or whether anyone has found a workaround that preserves native Button/Menu semantics and horizontal scrolling.

Answer 2

NSPsychic OP

1w

I encountered this same issue today: my fix was to apply .scrollEdgeEffectHidden(true, for: .top) on the inner (horizontal) scroll view (line 17 in your snippet).

In my case at least this work around doesn't affect the UI of my screen.

Answer 3

AlexRMuc OP

1w

Same class here on 24A5408d, but outside a horizontal ScrollView, which may widen the scope of this regression.

My container is a vertical SwiftUI Form (a preview area plus several controls, inside a NavigationStack with a pinned bottom bar). There is no horizontal ScrollView anywhere on that screen. The signature matches yours exactly: the element reports isHittable == true, the synthesized event appears to complete, and the bound value never changes.

Affected in my measurements, all in the same Form: Slider via adjust(toNormalizedSliderPosition:); Stepper increment buttons, four consecutive taps with the bound value unchanged; onTapGesture(coordinateSpace:) on a container view; simultaneousGesture(SpatialTapGesture()), the workaround DTS suggested in thread 795909 for FB19394663, equally ineffective here; and DragGesture on a view inside the Form.

Two differences from your report. First, it is intermittent, not consistent: the same synthesized tap at the same normalized coordinates was delivered in one run and dropped in the next. That also makes it impossible to gate in a test suite, since neither a positive nor an inverted expectation is stable. Second, it is far worse in compact height (landscape); in portrait the same controls mostly work.

The iOS 26.0 simulator (23A343) runs the identical app build reliably, and element geometry is bit-identical between the two runtimes for the same screen.

Filed as FB24381580.

NSPsychic, that is an interesting lead, thank you. Does scrollEdgeEffectHidden(_:for:) help only on the inner horizontal scroll view in your case, or does hiding the top edge effect on the outer, vertical container matter as well? Given that my failures are worst in compact height, where everything sits close to the top edge, and that the report above describes taps near the upper portion being ignored while the lower edge works, an edge-effect overlay would fit the pattern. I will measure it and report back.

Answer 4

Laketauponz OP

1w

Recommended

It appears Beta 6 has fixed the issue for me.