[TestFlight] “Lenslink just stop moving it doesn't let me interact witt an”

[github-actions]

TestFlight feedback — 2026-07-26 08:01:09 UTC

Lenslink just stop moving it doesn't let me interact witt anything, I can't even press the start streaming button. I don't know what happened. I have an Iphone 12.

App build	1045
Device	iPhone13_2 — IOS 17.6.1
Locale / TZ	en-PH / Asia/Manila
Network	WIFI
Battery / free disk	85% / 2.6 GB
Screenshots	0 — view in App Store Connect (download links expire)

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

[MyNamesEMurray]

@claude review this, i have tester's email address if we need to reach out.

[claude]

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

---

Review: "app stops responding, can't interact with anything"

• Gather context (issue + repo docs)
• Read app hub (Streamer.swift) and UI entry point (ContentView.swift)
• Read CameraManager.swift, StreamClient.swift, CameraPreviewView.swift
• Identify plausible root cause(s) for the freeze
• Post review findings

No code changes were made — this was a review request. I can't reproduce on this Linux container (no Xcode/device access), so this is a static read of the code with the tester's report as the lead. Findings below, most likely cause first.

---

1. CameraManager.configure() blocks the main thread synchronously — the likely freeze

CameraManager.swift:420-425:

func configure(...) throws -> StreamColor {
    try sessionQueue.sync {
        try configureOnQueue(...)
    }
}

This is called directly (not await-wrapped, no queue hop) from @MainActor code in Streamer.swift:1009 (start(), i.e. the path the "Start Streaming" button drives — ContentView.swift:315) and again in Streamer.swift:91 (reconfigureLiveCapture(), used for live lens/format switches). Since Streamer is @MainActor, this sessionQueue.sync call blocks the main thread for the entire duration of configureOnQueue — adding the device input, locking for configuration, assigning activeFormat, and commitConfiguration(). Format/session reconfiguration is documented elsewhere in this very file to take real wall-clock time.

Tellingly, CameraPreviewView.swift has an explicit comment about exactly this failure mode and is careful to never touch the session synchronously from main:

"Attaching/detaching the preview layer takes the session's internal lock; doing it on the main thread while stopRunning() (1–3 s) holds that lock on the session queue freezes the whole UI — the classic 'app hangs for a few seconds after stopping the stream'."

configure() doesn't follow that same discipline — it's a direct sync call from the main actor. On an iPhone 12 (older hardware, iOS 17.6.1) a session reconfigure — especially the first one after a cold launch, or one that hits the HLG/Log-unsupported-pixel-format degrade-and-retry path at CameraManager.swift:547-558 (which reruns the whole configuration a second time) — could plausibly stall the main thread long enough to look exactly like what the tester describes: the app "just stops moving," and taps (including on the Start Streaming button itself) go nowhere because the main run loop isn't processing UI events.

2. activeDevice is read/written from two queues without synchronization

configureOnQueue writes self.activeDevice = device on sessionQueue (CameraManager.swift:500), but withLockedDevice (CameraManager.swift:585-590) — used by setZoom, setExposureBias, setFlashlight, focus/white-balance/exposure setters — reads activeDevice directly from whatever thread calls it, which for all of these is the main actor (they're driven by Streamer's @Published didSets). Contrast with onSampleBuffer, a few lines above, which is explicitly guarded by callbackLock for exactly this reason. This is a data race, not obviously the freeze itself, but worth closing since a torn/racy read of a reference-counted AVCaptureDevice? is exactly the kind of thing that can manifest as a hang or crash under load rather than a clean failure.

3. Minor: three queue.sync calls per second on the main actor while streaming

Streamer.swift's adaptive-bitrate loop (inherits @MainActor since it's spawned from Streamer, an actor-isolated context) calls client.statsSnapshot() (StreamClient.swift:164-170), takeDroppedFrameCount(), and takeMaxSendDelayMs() (StreamClient.swift:543-557) once a second — all queue.sync onto the network queue. Under normal conditions this is quick, but it's a synchronous main-thread wait on a queue that's also handling all socket I/O; worth converting to async or caching if it ever shows up in a hang report tied to network stalls rather than start-up.

---

Suggested next step: #1 is the strongest lead and is a one-line-shaped fix (dispatch camera.configure(...) off the main actor and hop back before touching @Published state, the same pattern CameraPreviewView already uses) but I'd want to confirm the freeze correlates with pressing Start (vs. happening while idle/standby) before implementing — happy to do that as a follow-up if you confirm, or if you reach out to the tester and can share when in the flow it happened.