How on-device invisible marking and share records work, at a high level

If you hand the same-looking image to several people, and a copy later turns up, the hard part is usually not noticing it. The hard part is telling which send it came from. MarkPath approaches that as an on-device problem: the original stays on the phone or tablet, each share is prepared as its own copy, and tracing reads a mark locally against records that also live on the device.

This is a high-level walk through that flow, based on the public site and FAQ. It is not an implementation paper, and it does not describe how the mark is embedded.

What stays on the device

Originals are encrypted on the device and work offline. You can add images from Photos, a scan, Files or the camera, and merge multi-page images into one item. Preparing a share never changes those originals.

Organizing, preparing shares and tracing all happen on the device. The app does not scan your photo library; it only handles images you choose. There are no ads, and no third-party analytics SDK. The purchase flow never uploads image content, recipients, purposes or trace results.

Network use is limited to the cases the site names. Purchases need a connection. iCloud sync is off by default; if you turn it on, images are encrypted before they go to your own private iCloud space. Encrypted backup, on the Pro plan, is protected by a recovery phrase you set and is fully verified before restoring. The default path for keeping, sharing and tracing does not send the image to a server to be marked or matched.

Preparing a share

A share is not “the original, sent again”. It is a new copy, prepared for a named recipient and purpose. You pick the pages, write who it is for and what it is for, and optionally add a visible watermark that states the purpose. The visible watermark is a reminder on the page. It can be left off.

The invisible tracking mark cannot be turned off. The app embeds a unique invisible mark and a content credential in every page of the share, then self-checks each page before handing anything to the system share sheet. If any page fails, nothing is produced.

Every share gets a new mark and a new record. Earlier shares are never changed. If you send the same original to three people, you get three copies that look the same, each carrying a mark that belongs to that one share.

The app handles still images only: no PDFs, video or animated images, and no OCR or automatic redaction. There is no export that bypasses “Prepare share”: every send is meant to be on record.

What a share record holds

Each share keeps the recipient, the purpose, the pages and the system-share result. That last point is narrower than it sounds. The record says whether the system share action completed, not that the recipient got the image. It is a record of what you prepared and handed to the share sheet, not a delivery receipt.

Tracing a copy later

When a copy resurfaces, you pick it in Trace. The app reads the mark on the device and matches it against your share records. If it can, it shows the source item, the recipient, the purpose, the matched page and the time of the share. The image you picked is not saved to your library and is not uploaded.

Detection stays high after everyday compression, screenshots and crops. Excessive compression, heavy cropping or heavy editing can make a mark hard to read. Choosing “Save to Files” in the share sheet keeps the original output, which is the safest option at the point you send.

Free and Pro have identical mark and detection quality. Paying does not change the quality of the mark, and it does not make a damaged copy more readable.

The five results, and why they are this explicit

The product does not collapse every read into “match” or “no match”. It names five outcomes, and each one says what it does and does not tell you:

• Source found: the mark verifies and matches a share on this device.
• Mark detected, no matching record: the mark came from your MarkPath, but this device has no matching record. It may have been deleted, not yet synced, or belong to another library.
• Possible matching shares: the mark did not verify, but leftover clues resemble some of your shares. A match score is not a probability of origin. Use it as a reference only.
• No recognizable mark found: the image may never have carried a mark, or may have lost it. That does not mean it has no source.
• Sources contradict each other: both checks passed but point to different shares. The app will not pick one for you.

These results are leads for your reference. They do not prove an image is authentic and are not legal evidence. If a file is forwarded several times outside the app, the mark cannot tell you which forward it was.

Why the limits are part of the design

An on-device mark and a local share record can answer a specific question: which of my sends does this copy look like. They cannot stop forwarding, cannot speak for what happened after the file left the share sheet, and cannot stand in for a legal finding.

The shape should be familiar if you think in terms of client-side processing. The original does not have to leave the device for a share to be prepared. The mark is unique per share, not per library item. Verification happens next to the records written when you sent the file. When the read is unclear, the app is expected to say so, rather than force a single answer.

Disclosure: I work on MarkPath, an iPhone and iPad app from HapData. This walk-through follows the public product description and FAQ at markpath.app.