Skip to content

iOS: stop the dim-fuse gesture from eating the settings form's taps - #101

Merged
MyNamesEMurray merged 1 commit into
mainfrom
claude/issues-91-93-obs-updates-m5z1vp
Aug 7, 2026
Merged

iOS: stop the dim-fuse gesture from eating the settings form's taps#101
MyNamesEMurray merged 1 commit into
mainfrom
claude/issues-91-93-obs-updates-m5z1vp

Conversation

@MyNamesEMurray

@MyNamesEMurray MyNamesEMurray commented Aug 7, 2026

Copy link
Copy Markdown
Owner

What & why

Fixes #89
Fixes #96
Fixes #97
Fixes #99

The standby dim reset its fuse via a simultaneousGesture(DragGesture(minimumDistance: 0)) on the whole settings Form (f03e8bd, late July). A zero-distance drag competes for every first touch: menu-style pickers stopped opening on single tap on some iOS releases — the whole Camera & color section looked locked at its defaults (#96, #99, reproduced by five reporters across iPhone XR→16e on iOS 18.7/26.x) — and the RPSystemBroadcastPickerView overlay stopped receiving single taps everywhere, since touches a SwiftUI gesture claims are withheld from UIKit subviews (#97, regression window builds 1038→1054 matches the gesture landing). The reporters' two-finger workaround was the second touch slipping past a drag that only tracks the first.

Replaced with TouchActivitySensor: a window-level UIKit recognizer that fires on touchesBegan and immediately fails itself — it observes touch activity for the dim fuse without ever winning, delaying, or cancelling another recognizer, and never withholds touches from UIKit views. Same fuse behavior (any touch resets it), zero participation in gesture arbitration.

Carries Release-Bump-wise: Release-Beta: true — ships to TestFlight as the next 1.10.0 beta without cutting a new stable Latest.

How it was tested

Swift parse check passes (ios-app/syntax-check.sh); the full type check is this PR's macOS CI job. Behavioral verification needs devices: the broadcast-row single tap reproduces on the maintainer's phone (pre-fix) and should work in the next build; the picker fix lands with TestFlight testers on the affected iOS versions (18.7.9, 26.5.2, 26.6). The dim-fuse still resets on any touch by construction (the sensor reports every touch-down).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AeWct1Rvpqi4ptgogiwsCL


Generated by Claude Code

The standby dim reset its fuse via a SwiftUI
DragGesture(minimumDistance: 0) simultaneousGesture on the whole
settings form (f03e8bd). That gesture competes for every first touch:
menu-style pickers stopped opening on a single tap on some iOS releases
(the whole Camera & color section looked locked at its defaults —
issues #96, #99), and the RPSystemBroadcastPickerView overlay stopped
receiving single taps everywhere, since touches a SwiftUI gesture
claims are withheld from UIKit subviews (issue #97). The reporters'
two-finger workaround was the second touch slipping past a drag that
only tracks the first.

Replace it with TouchActivitySensor: a window-level UIKit recognizer
that fires on touchesBegan and immediately fails itself, so it observes
touch activity without ever winning, delaying, or cancelling anything.
Same behaviour for the fuse (any touch resets it), no participation in
gesture arbitration at all.

Fixes #96
Fixes #97
Fixes #99

Release-Beta: true

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeWct1Rvpqi4ptgogiwsCL
@MyNamesEMurray MyNamesEMurray added the bug Something isn't working label Aug 7, 2026 — with Claude
@MyNamesEMurray
MyNamesEMurray merged commit d7052d7 into main Aug 7, 2026
6 checks passed
@MyNamesEMurray
MyNamesEMurray deleted the claude/issues-91-93-obs-updates-m5z1vp branch August 7, 2026 10:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

2 participants