parawanderer/OpenTagViewer

Spike, and openly the lowest-priority thing in this repository. Nobody has asked for it. It is recorded because it is a real asymmetry in what this app does, and because somebody curious might want it. The asymmetry Every location this app shows was uploaded by a stranger's iPhone. An AirTag has no network of its own: it broadcasts a rotating public key over BLE, some passing Apple device hears it, works out where it is, encrypts that to the tag's key and hands it to Apple. This app reads those reports. It has never produced one. Every OpenTagViewer user takes from the Find My network and gives nothing back. That is not a bug — the app had no Bluetooth at all until recently — but it is worth being honest that "we depend entirely on other people's phones doing the thing we don't do". @ubrt's local Bluetooth scanning (#48, #139) changes the prerequisite: once the app can hear offline-finding advertisements at all, the radio half of this is largely solved. It listens for your tags tod

Spike, not a feature request. The deliverable is a document saying whether this is possible and how, not working code. Code follows if the answer is yes. Why this is the last one Everything this project set out to remove is gone. The macOS VM, the Find My app, reading plists off a disk, the export being tied to one operating system — all replaced by an Apple ID, a passcode and iCloud. The findmy-export specification covers six stages end to end, and the write half works: an implementation built from Stage 4 §4 saves records that Apple's own Find My displays correctly. One requirement is left, and it is worth naming precisely: Registering an AirTag requires an iPhone or an iPad. Not a Mac — macOS cannot set up an AirTag at all, at any version. So the remaining dependency is not "an Apple device", it is specifically iOS or iPadOS. Close this and the project is 100% iOS-free: buy a tag, register it from Android, locate it from Android. The tag is still an Apple product and the acco

The app can already find the owner's own iPhones, iPads and Macs — they sit in the Find My zone alongside the tags, they carry key material, and FindMy.py locates them the same way it locates an AirTag. What it cannot do is keep them up to date, and that gap is invisible from the outside. Why a device in this app looks broken when it isn't An AirTag has no network of its own. It broadcasts a rolling public key over Bluetooth, some passing iPhone hears it, and that stranger's phone uploads an encrypted report. Reading those reports is what this app does, and for a tag it is the only mechanism — so this app and Apple's own app are doing the same thing and get the same answer. A phone is not like that. It has a network connection, and it reports its own position to iCloud directly and continuously. Apple's Find My app reads that. The crowd-sourced beacon path still exists for a device — which is why one shows up here at all — but it only produces a report when the device is broadc

What happens Open Settings → check the items in your Apple account while a first import is still resolving tags, and the screen sits on a spinner for minutes. Until recently it could not be left at all, and it claimed to be "Looking for a device that can unlock it…" — for an account that had just been linked and would never need a device. The lock-in and the wording are fixed. The waiting is not, and this issue is about that. Why Every call into Python is serialised by PythonLock, and the reason given in its docstring is that the iCloud flow and the location fetch share one Apple session, because two sessions would be two devices to Apple (rule 11). Sharing the session is not what forces the serialisation. Apple has no objection to two concurrent requests from one device. What forces it is how the shared event loop is driven: icloud_bridge.openSession reaches into account._evt_loop and reuses FindMy.py's own loop — correctly, so there is one session and one identity but both s

Export History writes a tag's stored history as CSV. Nothing reads one back. Why this is different from the rest of the feature list Location history is the only data in the app that cannot be re-fetched. Apple serves a short window of reports, so anything older than that exists solely in the app's own database. Everything else survives a reinstall one way or another — tags come back from a bundle, or on their own once the app reads them from the user's Apple account — but history is gone the moment the database is. And it goes more often than you would think: allowBackup is false, so wiping app data, moving to a new phone, or uninstalling takes it all. The user is told to keep an export; today that export is a dead end, because there is no way to put it back. Shape The app defined the format itself, so this is reading its own output: Parse the CSV Export History writes — it already carries timestamp_utc, timestamp_local and timestamp_epoch_ms Insert into Room, deduplicating on