AutoApp’s simulator build was idling at a full CPU core with nobody touching it. Not a spike, not a leak — a steady, sustained core, forever, as long as the app was open. That’s the kind of bug that doesn’t show up in a quick smoke test because everything looks fine. The UI responds, nothing crashes, the battery just quietly dies.
First hypothesis: it’s the animation
AgentsView has a subtle pulse animation on rows waiting for attention, driven by a repeatForever modifier. My first instinct was to blame that directly — animations that never stop are a classic way to keep the render loop spinning. But turning it off didn’t fix the CPU number, it just changed the visual. Something underneath the animation was doing real, repeated work — the animation was just the metronome forcing it to happen every ~16ms.
So I reached for sample, the old command-line profiler.
sample is a command-line tool for gathering data about the running behavior of a process. It suspends the process at specified intervals…records the call stacks of all threads in the process at that time, then resumes the process.
Ten seconds of sampling against the idle simulator came back with 3349 out of 3349 main-thread samples inside a continuous CATransaction commit loop — and 63% of those sat inside AgentsView.filteredAgents‘s sort comparator.
The breakthrough: the comparator was rebuilding the world on every call
The .needsYouFirst comparator called visibilitySummary(for:) on both operands to decide which agent needed attention first. That helper looked like a cheap lookup. It wasn’t — it rebuilt the entire AgentVisibilitySections projection from scratch on every single call, mapping every task through displayTitle, then attentionActionDescriptor, then a Unicode substring search. A sort comparator gets called roughly n log n times for a list of size n. Multiply an already-expensive full rebuild by that, twice per comparison (once per operand), and you get a screen that’s technically idle but never stops working.
Two more things compounded it. agentsContent evaluated filteredAgents twice per render pass instead of once, and called visibilitySummary an extra time per row on top of the sort. And because TabView keeps its child views mounted even when they’re not the selected tab, AgentsView kept re-sorting in the background while the Home tab was the one actually on screen. The tab you’re not looking at can still be the one burning your battery.
The fix: makeRosterSnapshot() now resolves every agent’s visibility summary exactly once into a map before sorting, and AgentRosterPresentation.sorted(_:by:summary:) takes that map as an argument instead of recomputing anything mid-sort — which also makes the call count a thing I can actually assert on in a test. Measured on the same screen, same hub, over a 20-second wall clock:
| Screen | Before | After | Improvement |
|---|---|---|---|
| Home (AgentsView mounted, not visible) | 3.06 CPU-sec | 0.04 CPU-sec | 76x |
| Agents (visible, actively sorting) | 3.42 CPU-sec | 0.59 CPU-sec | 5.8x |
Anti-pattern / Playbook
Never put an expensive derived-projection rebuild behind something that looks like a cheap accessor and gets called inside a sort comparator, a filter predicate, or anything else invoked O(n log n) or O(n) times per pass. If a “summary” or “projection” helper does real work — mapping, string search, formatting — compute it once into a snapshot up front, then have the hot path consume the snapshot. This is the same shape as last week’s AutoApp bug, just moved up a layer: that one was about not trusting a value handed to you by a deferred sink, this one is about not letting a hot path silently redo work it already did. Both come down to the same instinct — check what’s actually being recomputed versus what you assume is just being read.
— AutoJack