For short, on IOS scrolling on clicking on the pressable area is not possible except wrapping the whole item box inside the list-view element, on Android it scrolls in all cases, doesn't matter what is the parent container, list or column or scroll-view.
the reason why I don't want to wrap inside list-view is that it's not fully customizable. for example I can't give a gap between each item boxes.
Here is the AI investigated possible reason:
"Root cause (as far as I can tell): TapModifier (SwiftUINodeRenderer.swift) wires @press/@Navigate via a plain .onTapGesture, with no .simultaneousGesture wrapping — so it can claim the touch exclusively before the ancestor scroll gesture recognizes it. Compare to NodePressFeedbackModifier (drives press-scale), whose own comment says it deliberately uses .simultaneousGesture(DragGesture(minimumDistance: 0)) "so scrolls aren't blocked" — that fix doesn't appear to be applied to TapModifier."
For short, on IOS scrolling on clicking on the pressable area is not possible except wrapping the whole item box inside the list-view element, on Android it scrolls in all cases, doesn't matter what is the parent container, list or column or scroll-view.
the reason why I don't want to wrap inside list-view is that it's not fully customizable. for example I can't give a gap between each item boxes.
Here is the AI investigated possible reason:
"Root cause (as far as I can tell): TapModifier (SwiftUINodeRenderer.swift) wires @press/@Navigate via a plain .onTapGesture, with no .simultaneousGesture wrapping — so it can claim the touch exclusively before the ancestor scroll gesture recognizes it. Compare to NodePressFeedbackModifier (drives press-scale), whose own comment says it deliberately uses .simultaneousGesture(DragGesture(minimumDistance: 0)) "so scrolls aren't blocked" — that fix doesn't appear to be applied to TapModifier."