Loupe: an iOS app that shows the values any app can read from your iPhone

The problem Loupe addresses: fingerprinting without identifiers

Most privacy advice assumes the threat is a name, an email address, or a location fix. Loupe starts from a different premise, stated in its README: trackers do not need any of those to recognise you, because each reading a third-party app can pull from public iOS APIs is not necessarily unique on its own, yet together the readings form a fingerprint that follows a person across apps and websites. The app is aimed at people who want to see that surface rather than read a description of it. It reads real values from the same public APIs any third-party app can call and displays them raw, with no aggregation and no hashing. That design choice matters. A hashed or bucketed view would be easier to look at, but it would hide exactly the detail that makes a fingerprint work. The audience is narrow and specific: developers learning what iOS exposes, privacy researchers, journalists who need a screenshot, and anyone teaching a class where "your phone leaks data" needs to become a list of concrete values.

Three tiers, sorted by the cost of access

Loupe organises every reading into three categories that reflect what an app has to spend to get the value. Passive readings are visible to any app with no prompt at all, and the README names locale, time zone, screen and battery among them. Needs Permission readings trigger an iOS prompt, and the examples given are contacts, photos, location and calendars. Advanced readings are side-channel uses of public APIs, and the README cites URL-scheme probing through canOpenURL and Keychain persistence across reinstalls. That third tier is the most interesting part of the design, because it shows that some signals require neither a permission dialog nor a special entitlement. The tiering is also the app's main didactic device: a reader can see at a glance which values cost a user nothing to give away and which ones require a tap on Allow. The README does not document a scoring model, a uniqueness estimate, or a per-signal explanation of how many bits of entropy a value contributes. What you get is the raw reading plus the tier it belongs to, and the interpretation is left to the reader.

Installing Loupe and reading your first signal

There is no package manager, no Homebrew formula and no TestFlight link in the README. The published route is the App Store listing linked from the README badge. Building from source is documented for people who want to read the code or run it on a Mac.

The README states that Xcode 26 or newer is required. The steps are: open the project, create a local signing configuration, and build. The signing file is gitignored and never published, so you supply your own team and bundle identifiers.

cp code/Config/Signing.local.xcconfig.example code/Config/Signing.local.xcconfig

After copying, fill in your own DEVELOPMENT_TEAM and bundle identifiers in that file, then open code/Loupe.xcodeproj and build for a device or simulator. The README notes that the project uses Xcode buildable folders, so new Swift files are picked up automatically without editing the project file. A macOS build also exists; the README describes the Mac version as mostly complete, with a few things still needing work before it is polished. For a first real use, open the passive tier and read the values listed there. Those are the ones an app obtains with no prompt, so they are the right starting point for a demonstration.

Where Loupe stops: display, not defence

Loupe is the wrong tool if you want to change what your device exposes. Nothing in the README describes blocking, spoofing, randomising or restricting a signal. The app reads and shows. Its privacy section is a statement about data handling, not about protection: nothing it reads leaves the device unless you explicitly export it, and nothing is uploaded, synced or shared. That is a meaningful property for a tool that displays device identifiers, because a cloud dashboard would defeat the purpose, but it is not the same as hardening a phone. The tier model can also mislead by implication. Seeing a passive value such as a time zone in a list may suggest it is a serious identifier on its own, and the README explicitly warns against that reading by saying each value is not necessarily unique alone. The app gives you the ingredients and leaves the arithmetic to you. There is a second boundary worth naming: the App Store listing is the distribution channel the README points to, and the README does not state a minimum iOS version, so the supported range has to be checked on the listing itself rather than in the repository.

How Loupe differs from browser fingerprinting testers

The obvious comparison is a browser fingerprinting test page such as those that render a canvas hash in a web page. The approach is different in kind. A browser test measures what a web engine exposes to JavaScript inside a sandbox, and its results are shaped by the browser's own anti-fingerprinting decisions. Loupe measures what the operating system exposes to a native app, which is a larger and less mediated surface: the passive tier alone includes device-level values that no web page can reach, and the advanced tier covers API side channels such as URL-scheme probing that have no browser equivalent. The trade-off runs the other way too. A browser test runs anywhere with a URL, while Loupe needs an iPhone, an iPad or a Mac build. If your question is what a website can learn about a visitor, Loupe answers a different question. If your question is what an installed app can learn, the browser test cannot reach that layer at all.

Maintenance, licence and the AI-authored note

The repository was last pushed on 2026-09-10, and it is not archived, so the code is recent as of this writing. The README does not publish a release history, a changelog or a support policy, and no releases were retrieved, so upgrade cost is hard to estimate: there is no versioned artefact to track and no documented deprecation path. Two licence facts need care. The repository metadata reports the licence as NOASSERTION, while the README states that the source code is released under the MIT License and that the Loupe name and logo, the app icon, all other images and icons, and the design source files are copyright Mysk with all rights reserved and not covered by MIT. A fork can reuse the Swift code under MIT terms, but it cannot ship the branding or the artwork. Anyone planning a derivative app should read the LICENSE file directly rather than rely on the repository's licence field, and should treat the trademark and asset carve-out as the real constraint. The README also states plainly that Loupe was written almost entirely by AI coding tools, which is relevant if you intend to audit the code before trusting its readings.

Editorial conclusion

Adopt Loupe if you teach mobile privacy, write about fingerprinting, or want a concrete demonstration that a device can be recognised without a name or an email address. Skip it if you want a tool that blocks tracking, changes identifiers, or audits what installed apps actually do: Loupe reads and displays, and its README does not claim otherwise. Before relying on it, open the App Store listing to confirm the iOS version it requires, and read the LICENSE file, because the repository reports the licence as NOASSERTION while the README states MIT for the source code, and the name, logo and design files are excluded from that grant.

Frequently asked questions

Official sources

1. Issues
2. mysk-research/loupe on GitHub
3. README