One machine, and the app under a stopwatch
Retiring a MacBook, closing security holes verified by digest, and the performance number that turned out to be lying to us for months.
Two threads collided this week: a machine migration I'd been putting off, and a performance-and-security pass that turned out to need every bit of the extra clarity that comes from finally consolidating onto one Mac instead of splitting attention across two.
Security, verified the boring way
Every backend deploy this week went out the same way — pushed, then checked, with the
running ECS task's image digest compared against the digest that was just pushed. That
habit caught real mismatches before, and it's non-negotiable now for anything that touches
production. This round of deploys closed a handful of real holes: a self-closing
<object/> tag in the Apple Notes HTML parser that silently discarded the
rest of a note, a ReDoS in a trailing-whitespace trim, locked documents that could still be
downloaded or sent to a third-party vision model through a side door, OAuth state tokens
that were being accepted as if they were session tokens, and a trash sweep that ran with no
tenant bound and quietly collected nothing.
None of these were exotic. All of them were the kind of thing that only shows up when you go looking specifically for the ways an assumption could be wrong, rather than waiting for it to fail.
The number that was lying
The more interesting story is a performance instrument, not a performance fix. The app's FPS probe reported frames-per-second as display-link ticks averaged over a full second. A scroll flick lasts a few hundred milliseconds — so a second containing a 120Hz flick and 900ms of the screen sitting still would read out as roughly 60fps, indistinguishable from a screen that's actually capped at 60. Real conclusions had been drawn from that number, including some of mine.
The fix was to stop averaging away the thing that mattered: frame-interval buckets instead of one blended number, the device's actual maximum refresh rate alongside the sample so a 60fps reading against a 60Hz ceiling reads as correct instead of as a problem, and CoreAnimation's own frame budget, which finally distinguishes "the system is targeting 120 and missing it" from "the system was never asked for more than 60." Those need opposite responses, and the old number couldn't tell them apart.
That fix immediately surfaced something real: eighty samples showing a 16.67ms budget and
never an 8.33ms one — which is what exposed that a ProMotion opt-in key had been shipped
without its required OnPhone suffix and silently ignored for the app's entire
life. An unrecognized key in an Info.plist isn't an error. It's just a key nobody reads.
"Verified present in the binary" had been true the whole time, and entirely beside the
point.
What actually shipped on device
Beyond the fix itself: ProMotion is now genuinely enabled. The home compass stays static. The living sky's creature sprites are gone, chat transitions and the typewriter effect got trimmed enough that chat's median CPU sits at 0.7%, and a live voice call now belongs to its own conversation instead of bleeding into whichever one happened to be open. Some things stayed open on purpose — chat scroll still isn't as smooth as I want, and the fix for that is still an unmerged experiment waiting on a real verdict, not a guess.