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

> A proximity lock that locks the machine when the device in your pocket walks away; it became the SignalLock menu bar app.

- What it does today: Locks the macOS screen when the device you carry moves away; the call rests on a proximity assessment rather than a raw present/absent signal, so fluctuation no longer produces false locks. The menu-bar app is published and ready to install.
- Form: Open source
- State: Became a product
- Focus: Security & verifiability
- Started: 2026-03-01
- Left Labs: 2026-05-20
- Technologies: Swift, SwiftUI, CoreBluetooth, CoreLocation, C#, .NET 8
- Tags: #bluetooth, #macos, #security
- Source code: https://github.com/signallockapp/
- Website: https://signallock.app
- This one became a product: SignalLock (https://www.muhammetsafak.com.tr/en/portfolio/signallock/)
- Source: https://www.muhammetsafak.com.tr/en/labs/signallock-lab/
- Language: en-US
- Author: Muhammet Şafak

---
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.