[ios] Background CPU kill (cpu_resource_fatal): the Live strap-log card re-renders every buffered log line on each new line, even while the app is backgrounded #2521

NOOP version

10.8.0

Platform

iOS

OS version

27.0

WHOOP strap / Oura ring model

Oura Ring 3 (Gen3)

Where the data is coming from

Live Bluetooth (Oura ring connected)

Test Centre profile

Not a test-mode bug

What happens

Summary

On iOS the app is killed in the background by the CPU monitor (cpu_resource_fatal, 80 % of a core over 60 s). The kills before the re-score pacing work (#2296 / #2318 / #2334) had the re-score thread in almost every sample. The newest kill, on a build that has the pacing, has the main thread in 5 of 6 samples (4 with a full main-thread stack, 1 truncated inside SwiftUI), doing SwiftUI view updates while the app is not frontmost. One of those samples lands in LiveLogCard. From the code, LiveLogCard rebuilds a non-lazy list of up to ~5,000 log lines on every appended line, and it does this in the background too.

The kill (2026-09-27 03:13, iPhone18,1, iOS 27.0, 11.8.0 (419) debug build, Oura Ring 3)

Event:        cpu usage
Action taken: Process killed
CPU:          48 seconds cpu time over 57 seconds (85% cpu average), exceeding limit of 80% cpu over 60 seconds
Primary state: 5 samples Non-Frontmost App ... Effective Thread QoS Background, Requested Thread QoS User Interactive
Power Source: 6 samples on AC

Symbolicated app frames (the stack roots are StrandiOSApp.$main → SwiftUI/UIKit run loop → AttributeGraph):

main thread: 4 samples with the full stack (StrandiOSApp.$main → run loop), plus 1 truncated SwiftUICore stack:
  ...SwiftUI / AttributeGraph update...
    closure #1 in View.onChangeCompat<A>(of:perform:)            StrandDesign.swift:28
      closure #2 in closure #2 in closure #1 in LiveLogCard.body   LiveView.swift:1285   (1 sample)

concurrency thread, 1 sample:
  IntelligenceEngine.analyzeRecent(...) closure #9                IntelligenceEngine.swift:1528
    AnalyticsEngine.analyzeDay(...)                              AnalyticsEngine.swift:544/552
      SleepStager.sessionAvgHRV → sessionHrvWindows → Array.filter  SleepStager.swift:2959/3010

In the minute before the kill the app logged about 350 lines (a history drain on reconnect plus the re-score's per-day diagnostic lines), about 6 lines a second.

Earlier kills on the same phone, for the change in shape:

Why the log card is expensive (from the code)

• LiveState.log is a @Published array capped at maxLogLines = 5_000 (plus a 256-line trim slack). append(log:) appends one line at a time on the main actor, so every line publishes a change.
• LiveLogCard (Strand/Screens/LiveView.swift) renders it with ScrollView { VStack { ForEach(Array(live.log.enumerated()), id: \.offset) { Text(...) } } }. That is a non-lazy VStack over the whole buffer: every row is built and diffed on each change, and onChangeCompat(of: live.log.count) then calls proxy.scrollTo(last).
• Nothing gates this on scenePhase. A backgrounded app whose Live tab has been visited keeps the card alive and keeps paying the cost for every line.
• LiveState is one ObservableObject, so each appended line also invalidates every other view that observes it. That is likely part of the unattributed SwiftUI samples, but it is not shown by this report.

So the cost of one log line grows with the size of the buffer, which is usually full, and the drain / re-score bursts produce hundreds of lines a minute. This comes on top of the paced re-score's own CPU, and the 80 % budget is per process, not per thread.

Suggested fix (small, app-target only)

1. Render only a tail in the card, e.g. the last 200 lines, in a LazyVStack. The full buffer is still what Copy / Save / the export read, so nothing is lost.
2. Skip the update while scenePhase != .active, and catch up on return. The log is still written to disk by append(log:), so nothing is lost there either.
3. Optionally, move log out of the big LiveState object (or coalesce appends, e.g. per 250 ms) so a log line doesn't invalidate the rest of the UI.

Limits of this report

• The main-thread shape is one kill with 6 samples, and only 1 of the 5 main-thread samples is symbolicated into NOOP code (LiveLogCard). The other 4 are SwiftUI / AttributeGraph frames without an app frame, so which views they belong to is not shown.
• The mechanism above comes from reading the code, not from a profile. An Instruments Time Profiler run over a backgrounded drain would confirm the split.

How to reproduce

Visit the Live tab once, background the app, and let a large history drain plus a forced re-score run (for example, reconnect after a long gap). Watch for cpu_resource_fatal in Settings → Privacy & Security → Analytics Data.

What you expected instead

no crash

Steps to reproduce

1. see the general description

NOOP Staging.cpu_resource_fatal-2026-09-27-031359.ips.zip

Strap log

Before you submit

• I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
• I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
• I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
• I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, or — if I'm on an Oura ring — the Oura ring support table, and this isn't an already-known limit (e.g. SpO₂, recovery/sleep on the 5/MG, or no Recovery / HRV on a ring-only day).
• I've left out anything personal (strap serial, account email, raw export).