Apple shipped a photo you can prove is real. You cannot check it yet.Apple shipped a photo you can prove is real. You cannot check it yet.

Apple has published how Reference Image works. Pixel data is cryptographically signed at the sensor, before the operating system ever sees it, in a dedicated capture mode. The Secure Enclave signs the metadata the sensor cannot vouch for, such as digital zoom. Demosaicing and tone mapping happen in Private Cloud Compute, with the processing recorded in transparency logs so the transformations can be checked by anyone. The final signature is a composite post-quantum one combining RSA-3072 and ML-DSA-87.

It is opt-in, it is the iPhone 18 Pro and Pro Max, and it is the main camera sensor only. That is the whole surface today.

What it actually claims

The reporting is careful about this and it is worth being equally careful, because the gap between what the system establishes and what a reader will assume it establishes is where the trouble lives.

The claim is about provenance, not truth. A signed photograph of a staged scene is a signed photograph. What the signature rules out is the file having been generated or altered between the sensor and the reader, which is a narrower and more useful thing than it first appears.

There is no API, and we are not going to invent one

Neither MacRumors nor AppleInsider names a developer interface, and Apple has not announced one. So the honest position for any app handling user photographs is that you cannot verify a Reference Image today, cannot display a verified badge, and cannot build a feature on it.

That matters because this is exactly the shape of story a roadmap gets written around. A capability is described in technical detail, the detail is real, and somebody concludes a feature is available. The detail being real is not the same as the feature existing.

Documentation of how something works is not an interface to it.

The one thing worth doing now

Check whether your image pipeline destroys metadata, because most do and nobody chose it deliberately.

A typical upload path decodes an image, re-encodes it at a smaller size, strips everything that is not pixels, and stores the result. That is sensible behaviour for privacy - location data in particular should not survive an upload by accident - and it is also the behaviour that will discard provenance when provenance starts to matter.

• Know where your pipeline re-encodes. Usually one resize step, and usually nobody has looked at it since it was written.
• Know what it keeps. Stripping everything is a decision; inheriting it from a library default is not.
• Keep the original where the product justifies it. You cannot recover a signature you threw away.
• Do not start displaying trust signals. Absence of a signature will mean nothing for years, because it means an older phone far more often than it means a fake.

Why the design is interesting anyway

AppleInsider notes the contrast with C2PA, which signs after processing. Signing at the sensor and then proving the processing separately is a harder engineering problem and a better privacy position, because it does not require trusting the party that did the editing.

That distinction is worth understanding even if you never touch this API, assuming one arrives. Any system that asserts a file is unmodified has to answer the same question: who signed it, and what were they in a position to know at the time. Most such systems answer it worse than this one does.