How we measure

A performance-obsessed app should show its work. This page is how we arrive at the numbers on the home page, so you can reproduce them or call us on them.

Why this page exists

Kiikari was built because a menu bar analytics app on this Mac wrote about 20 GB to the SSD every day. That is the kind of thing a developer notices and a spec sheet hides. So the promise here is falsifiable: we publish the numbers, the method, the build and the date. If the numbers drift, this page changes with them.

What we measure, and with what

FigureToolWhat it captures
Disk writesfs_usage filtered to the Kiikari processBytes actually written to storage over a fixed window, extrapolated to a day.
CPUpowermetrics and Activity MonitorSteady-state CPU with the popover closed. Idle means idle.
MemoryXcode memory report, footprintResident footprint during normal use, not a first-launch spike.
NetworkRequest accounting inside the appBytes transferred per day in steady state, with analytics enabled.

The conditions

The budget is enforced in code, not in a promise

The numbers are not a marketing target we hope to hit. They are a test that fails the build if we miss it. Kiikari's continuous integration runs a byte-accurate simulation of a 30-day sync with analytics on and asserts a hard ceiling on disk writes. If a change would blow the budget, it does not ship. The published number is the observed number, and the ceiling sits comfortably above it.

Current numbers

Disk writes per dayunder 20 MB everything on
Idle CPU0.0%
Memoryabout 60 MB
Networka few MB per day

Last measured on the release build for the current version. We restate the current numbers in every release's What's New, so the receipt travels with the app.

Check it yourself

You do not have to take our word for it. Open Settings, Advanced, Performance inside Kiikari. It shows every network request the app makes and its own footprint, live, on your machine.

← Back to Kiikari