findphone: Bluetooth RSSI hunting from the macOS command line

The MDM case findphone was built for

Find My is the default answer to a lost phone, and it is the wrong answer in one specific situation: when the device is enrolled in MDM that disables Find My but the device is still sitting somewhere within Bluetooth range. In that case there is no cloud lookup, no ring, no map pin, and the only remaining signal is the radio in the laptop in front of you. findphone exists for that gap. It is a macOS 13 or later command line tool that surveys nearby Apple handhelds by signal strength, or tracks one named device as you walk around. The audience is narrow on purpose: people who already have a Mac, already have a terminal open, and need to know which corner of a room a handset is in. It is not a consumer find-my-phone app and the README does not present it as one.

Three RSSI sources, ranked by quality

findphone does not read one sensor. It merges three sources, in descending order of quality. The best is a GATT link: once the tool has connected to the device over BLE, readRSSI() returns a fresh measurement roughly three times a second. The second is passive BLE advertisements, which are sparse because Apple devices rotate their advertising addresses about every fifteen minutes and only include the device name on occasional packets. The third is Classic link RSSI, read out of system_profiler SPBluetoothDataType and keyed by the stable public address of a paired device. That third source carries a trap the README documents in unusual detail: macOS refreshes the value only every three to twelve seconds and serves a cached number in between. Over 112 polls at 0.4s, every poll returned a value, but the same value repeated for runs of 8 to 31 polls. findphone therefore counts a measurement only when the value actually changes. The reported measurement count is far lower than the poll rate, and that is the honest choice. Most tools in this space would happily print a smoothed line at the poll rate and let you believe it.

Installing the unsigned release and running a first hunt

There is no package manager install. The README points at the Releases page for a universal binary, and notes that it is unsigned, so macOS quarantines it on download. The xattr line clears that attribute before the first run.

tar -xzf findphone-macos-universal.tar.gz
xattr -dr com.apple.quarantine findphone
./findphone --help

If you would rather build it, the Swift toolchain from Xcode Command Line Tools is the only prerequisite and the project has no dependencies. The README gives swift build -c release, then copies the product into ~/bin. A separate script produces the universal arm64 plus x86_64 binary that CI ships.

swift build -c release
cp .build/release/findphone ~/bin/findphone
./scripts/build-universal.sh dist

On first run the tool needs Bluetooth access for whichever terminal is running it, granted under System Settings > Privacy & Security > Bluetooth; the README says it will tell you if the permission is missing. Three modes are documented. Bare findphone surveys every nearby Apple handheld by signal. findphone iphone hunts one device by name, case-insensitively. findphone --list prints paired devices and their addresses.

findphone            # survey mode
findphone iphone     # hunt mode, name is case-insensitive
findphone --list     # paired devices and their addresses

In hunt mode you walk slowly and watch the bar. The reading is negative dBm, closer to zero when nearer: -45 and up is roughly arm's reach, -60 is the same table, -72 is the same room, -85 is far or behind cover, and below that is very far or shielded.

The --sound mode, and why it is not a Geiger counter

Adding --sound in hunt mode emits clicks that speed up as you close in, the way a parking sensor does: about one a second across a room, rising to a buzz once the signal reaches roughly -50 dBm, which the README places at about where a laptop sits on top of the phone. The point is to sweep a room by ear instead of watching the screen. Clicks stop when contact goes stale, so silence means no signal rather than no device, which is a distinction that matters when you are crawling behind furniture. The README pre-empts the obvious comparison: a Geiger counter clicks once per detected particle and its rate is the measurement, whereas here the rate is computed from the smoothed signal. Packets arrive on a fixed 0.3s polling timer, so their arrival rate says almost nothing about distance. That is a fair self-criticism. The click rate is a rendering of the smoothed RSSI, not a physical count, and anyone who treats the two as equivalent will misread the tool.

Signal strength is a coarse proxy, and the README says so

The limitation section is the most useful part of the documentation. Metal, walls and human bodies attenuate RSSI heavily, so a device in a filing cabinet two metres away can read the same as one fifteen metres away in open air. The README's instruction is to trust the trend as you move, not any single number. That is correct and it also means the tool cannot answer the question people actually ask first: which direction. One radio yields distance only, not direction, so there is no bearing, no arrow, no hot-cold map. You get a scalar and you supply the walking. The second hard limit is that findphone cannot make a device ring. There is no path to that without Find My, and no amount of CLI work changes it. The third is range: only devices with Bluetooth powered on and in range are found, roughly 10 to 20 m indoors and much less through walls. If the phone is off, out of the building, or in a bag inside a metal locker, findphone is the wrong tool and no amount of sweeping will change that. It also will not help with a non-Apple device in hunt mode, since the survey mode is described as covering Apple handhelds.

How findphone differs from Apple's own Find My

The real alternative is Find My, and the difference is architectural rather than a matter of features. Find My is a network service: the device reports its position through Apple's infrastructure, so it works across the city, survives the device being asleep in another building, and can trigger a ring. findphone is a local radio measurement. It has no server, no account, no map, and no ring, and it stops working the moment you leave Bluetooth range. What it has instead is independence from Find My enrollment state. That is the entire trade: you give up range, direction, ringing and history, and in exchange you get a reading on a device that the Find My stack will not talk about. If Find My works on your device, use Find My. findphone is the fallback for the MDM case, and the README frames it that way rather than pretending to compete.

Screen recording, --redact, and what stays visible

The --redact flag exists for people recording their screen. It masks Bluetooth addresses, and in survey mode replaces discovered device names with the device kind, since those names are not always yours. The reasoning in the README is specific: a public address is a stable hardware identifier and, unlike a BLE advertising address, does not rotate, so it is worth keeping out of a video. Two things stay visible deliberately. The name you typed in hunt mode, because you typed it. And the names in --list, because picking a target means reading them. The README states plainly that --list is not safe to film even with --redact. That is the kind of boundary most tools leave for the user to discover after publishing a demo.

Maintenance, licence and upgrade cost

The last push to the repository was on 2026-08-01, and the only release listed is v0.1.0 from 2026-07-31. This is a young, single-release project with no dependency graph: Package.swift is the only build manifest at the top level, alongside Sources/, scripts/ and .github/. The README states there are no dependencies, which means upgrading is mostly a matter of replacing the binary or rebuilding with swift build -c release, and there is no lockfile churn to manage. The repository is not archived, but with one release and a version number still at 0.1.0, treat the interface as unsettled. The licence is not stated in the README or the repository metadata, so anyone planning to redistribute the binary or vendor the source needs to confirm the licence terms from the repository itself before doing so. That is a factual gap, not a legal opinion.

Editorial conclusion

Adopt findphone if you administer MDM-managed Macs where Find My is disabled and you need a rough which-corner-of-the-room answer from a terminal, and you accept that the tool is unsigned, macOS-only, and reads distance without direction. Do not adopt it if you need a device to ring, if you need a bearing, or if you expect a stable distance number rather than a trend. Before relying on it, verify three things: that the target device has Bluetooth on and is within roughly 10 to 20 m, that the terminal running it has Bluetooth permission under System Settings > Privacy & Security > Bluetooth, and that the binary you downloaded clears quarantine with xattr -dr com.apple.quarantine findphone, since the release is unsigned.

Frequently asked questions

Official sources

1. ben-z/findphone on GitHub
2. Issues
3. README
4. Releases