[TestFlight] “Could not toggle the start screen broadcast for the updated ”

[github-actions]

TestFlight feedback — 2026-07-26 20:29:14 UTC

Could not toggle the start screen broadcast for the updated build v1.8.1 (1045).

App build	1045
Device	iPhone15_5 — IOS 26.5.2
Locale / TZ	en-GB / Asia/Manila
Network	WIFI
Battery / free disk	65% / 27.3 GB
Screenshots	1 — view in App Store Connect (download links expire)

Tester identity is omitted on purpose; it is visible in App Store Connect.

[MyNamesEMurray]

@claude user couldn't start the screen share, review and see if this should be fixed in later build than 1045?

[claude]

Claude finished @MyNamesEMurray's task in 2m 2s —— View job

---

Todo

• Gather context (issue body, trigger comment, CLAUDE.md)
• Investigate the broadcast-start failure path (SampleHandler.swift, StreamClient.swift, project.yml)
• Check what diagnostic info this feedback item actually contains
• Determine if this points to a fixable regression or needs more data
• Post findings/recommendation

Review

This is a screenshot-feedback TestFlight submission (testflight_feedback.py's screenshot path, not the crash path) — it's the tester's own typed comment plus a screenshot in App Store Connect, not a crash log or OBS log. That matters: it's the tester's paraphrase of what happened, not necessarily the literal system alert text, and there's no stack trace or counters to pin down which stage failed.

I reviewed the broadcast-start path this feedback would exercise:

• ios-app/BroadcastExtension/SampleHandler.swift:93-155 (broadcastStarted) — already retries a port bind conflict up to 4× (0.5s apart) before failing with a descriptive alert pointing at "stop the camera stream first" (one stream per device), and separately runs a 30s watchdog that fails with a specific message ("OBS did not connect... check OBS has a LensLink Screen source pointing at this phone") if nothing ever connects.
• ios-app/Sources/StreamClient.swift:239-266 (listen) — already retries EADDRINUSE and Bonjour-advertise failures before surfacing anything to the extension.

Both of the failure modes that would plausibly produce a user-visible "couldn't start broadcast" alert already have retry logic and a specific, actionable error message — this doesn't look like a regression sitting unfixed in the current code. I couldn't find anything in this path that looks broken or was recently changed to break it (repo history here starts from a single squashed init commit, so there's no way to diff "what shipped in build 1045" vs. now via git).

Conclusion: not enough information to identify or fix a specific bug from this report. No code change made. To make this actionable:

• Check the attached App Store Connect screenshot for the exact alert text (I can't view it from here).
• If reproducible, ask the tester to grab the OBS log covering the attempt per docs/DEBUGGING-SCREEN-MIRROR.md → "Collecting a report" — the heartbeat/diagnostic lines there would show whether it's a port conflict, OBS never dialing in, or something new.
• Worth asking the tester whether the LensLink Camera stream was already running on the same phone at the time (the one-stream-per-device case is exactly what the existing error message calls out).