[ryanbr]

Summary

The Live screen's strap-log card rendered the whole 5,000-line buffer in a non-lazy VStack over Array(live.log.enumerated()). So every appended line allocated a fresh 5,000-element array and built and diffed every row, while the viewport is .frame(height: 200), about fifteen lines. A history drain plus a re-score burst emits hundreds of lines a minute, the 80%-of-a-core limit is per process rather than per thread, and iOS killed the app for 85% of a core over 57 seconds while it was not frontmost.

Addresses #2521, reported by @pipiche38 with a symbolicated microstackshot that traced the main thread into this card.

I verified the attached report independently. The figures match exactly (48s over 57s, limit 80% over 60s, 6 steps with 1 lost, iPhone18,1, iOS 27.0), and the main-thread shape is corroborated without needing symbols: the "Heaviest stack for the target process" is 4 samples rooted dyld → app → SwiftUI → UIKitCore → GraphicsServices → CoreFoundation, which is the main run loop. Every code claim in the report held.

What changes

The card draws the last 200 lines in a LazyVStack, and nothing at all while the scene is backgrounded. LiveState.maxLogLines stays 5,000, and Copy, Save and the export still read the archive from disk, so nothing is lost by drawing less.

Two details decide the shape, and both are the kind that pass review and then crash:

The tail is a slice, not a range. A LazyVStack realizes rows in a later main-actor turn than the body that produced them, on scroll, with no re-evaluation. A range indexed back into the live buffer would then read a buffer append(log:) may have trimmed in between, out of bounds. An ArraySlice is a copy-on-write snapshot, so the rows it hands out stay valid however the buffer moves. I had written the range version first; it is the more obvious code and it is wrong.

Its indices are absolute. Between trims an append shifts only the window edges, so every shared row keeps its identity and SwiftUI adds one row and drops one rather than re-identifying the list. It also means scrollTo(log.indices.last) always addresses a row that was actually built, which a leading window would not. A trim does still renumber, because Array.removeFirst shifts every element down, but that is once per trimSlack (256) lines and now touches 200 ids instead of rebuilding 5,000 rows.

Gated on .background rather than != .active deliberately: .inactive is also when iOS takes the app-switcher snapshot, and blanking the log there would be visible for no benefit. The kill needs sustained non-frontmost CPU.

Being exact about what the backgrounded branch still costs, since a later reader profiling a residual will want pointing at it rather than told there is nothing there: the header, the Divider and the NavigationLink are still built per appended line, and NavigationLink(destination:) constructs TestCentreView() eagerly, which evaluates its @State defaults and so performs three UserDefaults reads. Microseconds against the five thousand Text views this removes, and left alone rather than converted to a deferred destination, which would change navigation construction semantics for a cost I measured as negligible.

What this does not do

The report's third suggestion is untouched. LiveState carries 63 @Published properties, so an appended log line still invalidates every view observing it; that is real, and splitting the object is an architectural change rather than part of this. What this changes is the cost of each invalidation, which is what the CPU limit measures.

It also does not address the concurrency sample in the same report. SleepStager.sessionHrvWindows re-scans the whole R-R segment once per five-minute window, so an eight-hour night is about 96 passes over the night's beats, and it is called about five times per sleep session per analyzeDay. That is a separate change to a hot path that produces shipped HRV values, so it deserves its own PR with an exact-output oracle.

Parity

None needed, and I checked rather than assumed: Android exposes the strap log only through export, with no on-screen scrolling log card, so there is no twin of this view to fix.

Verification

• swiftc -parse on all three files, and python3 Tools/doc_comment_lint.py: clean.
• 7 new StrandTests cases on LiveState.renderedTail, including the two invariants above: that the scrollTo target is always inside the rendered tail (a leading window passes every count assertion and fails this one), and that the snapshot survives the buffer being trimmed underneath it.
• The range arithmetic was additionally checked against an independent implementation, since the Swift tests run on the macOS leg rather than locally: this host is Linux and the app target needs macOS.