It appears Beta 6 has fixed the issue for me.

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.