Lid Creak 2.2.0 — the lid-angle app FreeSlapMac never wrote

Reflection — Lid Creak 2.2.0

Four fixes, four different failures, one feature. The interesting part is that each one was only visible once the previous one was gone, and that I got to the last one by being told the number.

1. The switch was a decoration

FreeSlapMac 1.1.0 advertises "Lid Creaking Sound", stores _creakingEnabled, and ships creaking.mp3 in a 267-clip pack. Reading strings out of the binary was what settled it: there is no HID usage page 0x20 access and no reference to that asset anywhere in the code. The toggle writes a preference nothing reads.

The lesson is about evidence, not code. The UI said the feature existed; the binary said it did not. A screenshot would have agreed with the user ("it doesn't work"), a symbol dump explained why. When a feature "doesn't work", the first question is whether it is there.

2. "It works" was not the ask

The first build was a launchd agent running a Python script. It genuinely worked — it read the sensor and played the clip. The reply was: "is it an app?" and then "make it an app".

That is a fair distinction I had collapsed. Something that runs invisibly, with no icon, no window and no Force Quit entry, is a daemon, and a user cannot consent to, inspect or stop a daemon the way they can an app. "Working" and "being an app" are separate requirements, and only one of them was in my head.

3. The app opened to nothing

The Swift rewrite was a menu-bar accessory: LSUIElement = true, setActivationPolicy(.accessory). Double-clicking it when it was already running re-activated a process with no window — so the honest report was "the app doesnt open", while pgrep showed it had been running for days.

I had verified the wrong thing: my checks were pgrep, codesign, launchctl — all true, all irrelevant to "what does the user see when they double-click". The fix was structural (.regular, a real window, applicationShouldHandleReopen), and the verification had to change with it: render the window's own content view, and check isVisible / occlusionState / isOnActiveSpace.

Also worth recording: screencapture fails on this Mac ("could not create image from display") because screen recording is not granted, so a --snapshot mode that draws the window into a PNG from inside the app was the only way to see my own UI. Necessity, but a good one — it runs headless in a build script.

4. The sensitivity setting was arithmetically impossible

"the sensitivity didnt matter i did low and i angle changed 1 degree still creaked" — with the number included, which is what made it findable in minutes instead of hours.

v2.1.0 measured  speed = |Δangle| / 0.05 s
the sensor reports whole degrees → 1° / 0.05 s = 20 °/s
Low was 15 °/s

So the least sensitive setting was already more sensitive than the smallest movement the hardware can express. Every level fired. The thresholds were a distraction: three different numbers all above 20 behave identically on a 1° input, which is exactly what "the sensitivity didnt matter" describes.

The right response was not to raise the numbers. It was to change the quantity: measure speed across a span wide enough that quantisation stops dominating, gate on total travel, and require the condition to hold for more than one tick. The numbers then had something to scale against.

What I should have done at the start: write down the sensor's resolution, then check that the smallest possible movement sits below the least sensitive threshold. That one line of arithmetic would have caught it before a single build. It is now the first row of both the simulate suite and the boundary tests, named "the old bug".

What the fix bought, beyond this app

The decision logic is now a pure Detector fed by (time, angle) samples, with the sensor as just one caller. That turned an untestable hardware behaviour into three cheap modes — --simulate, --trigger-test, --record — and it is the reason the answer to "did you actually fix it" is a table of eight timelines instead of "try moving your laptop".

Honest about what is still unproven

• Everything is verified on one machine, one macOS version, one lid. The 40° jump threshold and the

0.5 s stall discard are reasoned, not measured against a corpus of real traces.

• The eight timelines are synthetic by construction: they prove the decision, not the acoustics.

Nobody has listened to a thousand creaks and graded them.

• The sound belongs to FreeSlapMac. That is a licensing boundary, and it also means the download is

inert on a Mac without it — the app says so rather than failing quietly, but it is a real limit of publishing a companion rather than a standalone.

• arm64 only, ad-hoc signed. Both are fixable (universal build; a Developer ID), neither was

worth doing for a personal utility.

• The 1.4 s cooldown is taste. It is the one number on the page that is not derived from anything.

The pattern worth keeping

Three of these four failures were the same mistake in different clothes: I verified the mechanism and called it the outcome. The daemon ran → "it works". The process existed → "it opens". The slider moved → "sensitivity works". Each time the user was reporting the outcome, and I was reporting the mechanism. The detector rewrite is the version of this where I finally built the outcome into the test: eight timelines that would have failed before the fix, and one row named after the bug report that started it.