Screen lock by Bluetooth proximity: present/absent is not enough

Asking whether a Bluetooth device is in range is easy; getting the answer right is a different job. The raw “present / absent” signal lies several times a second, and every lie is a wrong lock.

”Present / absent” lies

An unlocked Mac in a shared workspace is a privacy risk, and remembering to lock it should not be the user’s job. The solution tried: treat a Bluetooth device the user already carries (iPhone, Apple Watch, AirPods, a BLE tag) as a trusted device, and lock the screen when it leaves range.

The real subject turned out to be the signal itself. A Bluetooth signal fluctuates by nature; the device disappears from a few samples even while it is sitting on the desk. A lock that reads plain visibility locks the screen while the user is still in their chair.

Proximity assessment instead of visibility

The core of the app was built on a proximity assessment rather than plain visibility: a smoothed RSSI value is read together with a last-seen timestamp. The RSSI threshold, the away delay and the smoothing window are all user-adjustable; the defaults were deliberately chosen on the conservative side to minimise false locks.

Never going near the network

For a tool like this the cloud is the easy road: keep the device pairing on a server, sync the settings, add features like “find my desk”. All of it means an account system and a backend.

The constraint chosen was the opposite: the app makes no network requests at all. There is no backend server, no cloud sync, no account, no telemetry, no analytics; location services are not used and every setting stays on the user’s own machine.

The cost is plain — no sync across devices, no remote management — and with no usage data, the default thresholds rest on a conservative choice rather than a measurement. In exchange, a user who wants their screen locked does not have to hand the identity of the phone in their pocket to a server. For a security tool that is the right trade.

Two codebases, one algorithm

The second consequence of the zero-network decision is on the platform side. An app that never goes online, that scans Bluetooth continuously and triggers the screen lock, touches the lowest layers of the operating system it runs on: CoreBluetooth and the lock API on macOS, its own Bluetooth stack and session management on Windows.

A single cross-platform shell would have kept both versions in one codebase. The cost would have been writing that platform difference underneath the shell anyway and carrying a runtime on top of it — a heavy bill for a tool that sits in the menu bar and stays open all day.

The path chosen was two separate native versions: Swift/SwiftUI for macOS, .NET 8 for Windows. What is shared is not code but the proximity algorithm and the configuration model itself — the thresholds, the delay and the smoothing window mean the same thing on both sides. The maintenance surface doubles, the behaviour stays single.

The road to the menu bar app

It shipped as a menu bar app; the product page and the download live on their own domain. Details in the portfolio.