TapDPP is now in public beta on Android and iPhone — here's what you can do with any NFC tag

The shortest path from an idea to holding one

A Spatiotemporal Digital Product Passport (SDPP) answers a different question than a plain product URL. Instead of "who looked this up on the web?", it asks which tag was tapped, when, and where — and serves a different view accordingly. Until now, seeing that work meant deploying readers and standing up a backend. As of today, it takes a phone and a blank NFC tag.

TapDPP is now in public beta on both Android and iPhone, downloadable from QDat.io/tapdpp and fully interworking with the tapdpp.qdat.io playground. This post walks through what that unlocks.

Two betas, one wire format

Both clients speak the same MQTT wire format and write the same canonical tag URL, so a tag written on Android reads identically on iPhone — and vice versa. There is no separate "Android tag" and "iPhone tag": there is just the tag, and the (When, What, Where) of each read.

The playground: tapdpp.qdat.io

tapdpp.qdat.io runs the exact same QDat.io codebase an operator would self-host, kept publicly online so the loop closes end-to-end. Request demo credentials from the /demo form and you get a tenant scoped to you — you see your tags and nothing else. Operators wiring their own deployment simply swap the host for theirs; the tag, the app, the wire format, and the DPP view do not change.

What you can actually do with one NFC tag

Grab any blank NFC Type V (ISO 15693) or Type A (NTAG / Mifare Ultralight) tag and you can run the full loop:

What lives on the tag — and what doesn't

The tag carries an NDEF record with the canonical URL (and, on NDPP-compliant tags, an optional embedded payload). It does not carry the routing logic. Templates, fences, and history all live on the resolver, inside the operator's perimeter. That separation is the whole point: the tag is durable and dumb; the intelligence is server-side and revocable. A tag commissioned today still resolves in thirty years — the view it resolves to is whatever the operator decides at read time.

Why this matters

Classic web resolvers route by the requester's IP, assume the brand still runs a server, and assume an IP's geolocation is anywhere near the asset. None of that holds for an industrial asset on a multi-decade service life. SDPP routes on the physical read instead — the timestamp, the on-tag identity, and the reader's position — and serves from infrastructure the operator owns. TapDPP is simply the smallest possible demonstration of that model: no fixed readers, no backend to stand up first, just a phone and a tag.

Try it

For a private, on-premise deployment of the DPP module inside your own perimeter, book a demo.