I started building ProximityLock a couple years ago during a period of frequent travel. I still do travel actually but a bit less.
If you work from open spaces, coworking spots, airport lounges, hotel lobbies you can probably relate to this: sometimes you'd step away to grab coffee or use the restroom, and forget to lock the Mac and it would sit there with everything open.
The solution seemed obvious: my Apple Watch never left my wrist. When I walked away, it went with me. Measure Bluetooth signal strength. Lock the Mac automatically.
I wanted my own app for this. It was sort of a challenge. And I started building a simple console proof of concept. Basic proximity detection using CoreBluetooth APIs. If signal strength dropped below a threshold, trigger a lock command. It worked in the terminal and seemed good enough.
But real-world testing revealed that Bluetooth proximity detection is anything but simple.
Beyond the Proof of Concept
The console proof of concept worked in testing. But Bluetooth signals are inherently noisy and unpredictable.
Simple threshold detection had fundamental limitations. Set it too sensitive and false locks occurred frequently. Set it too conservative and actual departures weren't detected reliably.
Finding a Real Solution
The solution came from signal processing techniques used in navigation systems. The Kalman Filter. Instead of reacting to every signal change, the app tracks patterns over time. It distinguishes between minor movements or interference and actual departures.
The implementation got more complex, but the user experience got better. Interference doesn't trigger locks that much anymore. Walking away gets detected much more reliably.
Privacy and Security
macOS requires explicit permission for Bluetooth access. The app needs this to monitor device proximity. That's pretty much everything the app needs to function, even when sandboxed. No data gets sent anywhere, only the updater and license activation needs internet access.
Also, despite the app not being distributed via the App Store, it's still signed and verified by Apple to ensure it doesn't contain malicious code.
Energy Efficiency
Proximity detection has to balance accuracy with battery life. Too frequent checks drain the battery, but checking too rarely means missing when someone actually leaves.
The goal was keeping the app in the low to zero energy zone in Xcode's profiler. The app uses specific system-level optimizations: setting QoS class to utility level and binding threads to efficient CPU cores when available.
The app adapts its checking frequency based on what's happening. When signals are stable, it checks less often. When something changes, it scans more aggressively to stay responsive while saving battery.
macOS makes this trickier by putting apps to sleep or nap mode. The app had to detect when the system tries to suspend it and avoid it.
The App Store Decision
Early on, I had to decide whether to target the App Store or distribute directly. The reliable screen locking required private APIs like SACLockScreenImmediate that Apple doesn't allow in App Store submissions. AppleScript was an option, but it's not elegant and needs extra permissions too.
You can trigger the screensaver without special permissions, but that doesn't guarantee immediate screen locking unless the user has configured their settings properly.
Also, the aggressive Bluetooth scanning and prevention of app nap could likely cause review rejection.
Maybe in the future I'll create a stripped-down version that would be acceptable for the App Store. But for now, this is how it is.
Building Everything Else
This decision to go with direct distribution shaped everything else. Instead of Apple handling payments and updates, I had to integrate a licensing system and payment processing, and an auto-updater. On the plus side, the payment processing fees are lower than the App Store's commission. Thanks to Lemon Squeezy. Not sponsored :)
Also the website became its own technical project. Built with SvelteKit, hosted on Cloudflare pages.
Analytics, however, got tricky. I didn't want to use Google Analytics or anything else like that. But I still need to understand what's going on: visitors, downloads, etc. Nothing fancy, everything anonymous obviously, but it took quite some time to implement. Nevertheless, it was very interesting and fun to do.
Pricing Strategy
Subscriptions feel kind of strange for something that should just work and doesn't rely on anything third party - it's not a SaaS, it's just a piece of software you buy and own.
So the one-time purchase model aligned with most user expectations. $19.99 for unlimited use, with a 14-day trial and 30-day money-back guarantee. You don't want to pay for something you're not sure will work for you. Simple and transparent.
Current Status
ProximityLock now handles the complexity of the Bluetooth reality quite well. Kalman filtering prevents false triggers.
The development journey took longer than expected. And building ProximityLock taught essential lessons about user expectations, technical complexity, and the difference between "working in testing" and "working for real people in real environments."
Using it daily myself revealed bugs and edge cases that probably no amount of formal testing could uncover. Sometimes the simple idea becomes a complex implementation. But it has been and continues to be an interesting journey.