Reading a screen without slowing one down

The cost of a screen history is paid every interval, forever, in the background, while you are trying to do something else. So it has to round to nothing. Capturing a frame with ScreenCaptureKit, reading its text with Vision, encrypting it, writing it and indexing it takes about a third of a second and about one percent of a single core.

The cheapest work is skipped work

Most of that budget is never spent, because most intervals end at the change check — a comparison against the previous frame that costs almost nothing and decides there is nothing here worth keeping. How that check works is its own note.

The same text is not read twice

Text recognition is the expensive step. When a frame is close enough to the one before it that its words cannot have changed, LockTime carries the previous text forward instead of running Vision again. Reading a screen takes about 70 ms. Reusing what was already read takes about 1 ms.

The interface does not wait for the library

Listing a day out of a library of 20,000 screenshots takes about 1 millisecond. Laying out the strip of moments for a full day recorded once a second — 86,400 of them — takes 5.4 ms, comfortably inside a single 16 ms frame. The window stays at the frame rate of the display whether the library holds a week or a year.

One build for both machines

LockTime is Swift and SwiftUI throughout, shipped as one universal build for Apple silicon and Intel. That constraint has teeth. Optional semantic search stores its embeddings as 16-bit floats, and the obvious way to write those in Swift is Float16 — which exists only on arm64. Written that way, the app compiles and passes its tests on an Apple silicon Mac and cannot be built for Intel at all. The store writes IEEE binary16 through vImage instead, and a test pins the byte layout so it stays that way.

None of this is visible, which is the point. You should not be able to tell it is running.