Hiding the photos we didn't capture

I have a lot of photos of my dog. I also have a camera roll I'd never hand to another person.

Both of those things are true for almost everyone I know. The phone is the most personal object we own, and the camera roll is the most personal thing on it. It's a record of what once held our attention — screenshots of conversations, memes, things we saved from the web, photos other people sent us, and the few thousand pictures we actually took. Most of it is mundane. Some of it is for our eyes only.

And yet we hand the phone over. We pass it across the table and the other person swipes — one photo left, then another, then they're three screens past the thing we wanted to show them. Showing someone one photo shouldn't mean showing them everything. But that's the deal the camera roll offers.

MyOriginals is the tool I wanted for that moment. It hides everything we didn't capture — screenshots, downloads, group chat saves — quickly so the photo grid we hand over is just the photos we took.

Origin, not content

The first design decision was the most important one: MyOriginals filters photos by origin, not by content. It does not look at what is in a photo. It has no classifier, no opinion about whether a picture is embarrassing or not. It asks one boring question of every item in our libraries: does the metadata match a camera on our keep list?

That's a deliberate choice for this app. Vision models are the right tool for plenty of photo problems, but the one we're solving doesn't need them. Determining device origin is answered by a make and model check in the metadata. This keeps MyOriginals simple: no models to load, no expensive on-device compute chewing through our libraries, and no network round-trips.

We aren't ruling out classifiers entirely. Filtering by content — such as identifying sensitive or NSFW images — is a different problem with its own tradeoffs. If we add that capability in the future, it will rely on an on-device model to ensure photos are never uploaded. Because it requires heavier computation, it would be strictly opt-in.

Reading the metadata

Every photo and video in our libraries carries metadata describing how it was captured. For still photos that lives in EXIF; for videos it lives in the QuickTime / ISO base media file format metadata. The two fields that matter here are the camera make and model. A photo from my phone reports Apple / iPhone 16 Pro; a photo from a friend's camera (if they have a different phone) reports something else; a screenshot reports nothing at all.

On iOS, we read it through PhotoKit and ImageIO. We request the asset's data and read its properties without decoding the full image — for photos via CGImageSource, for videos via AVAsset. A typical read looks like this:

let source = CGImageSourceCreateWithData(data, nil)
let props = CGImageSourceCopyPropertiesAtIndex(source, 0, nil)
    as? [CFString: Any]

let tiff = props?[kCGImagePropertyTIFFDictionary] as? [CFString: Any]
let make  = tiff?[kCGImagePropertyTIFFMake]  as? String
let model = tiff?[kCGImagePropertyTIFFModel] as? String

From there, the rule is simple. If make and model match a device on our keep list, the item stays visible. If they don't, it gets marked to hide.

There's one edge case we don't handle: a photo someone shared with us that was captured on the same make and model as our phone. The EXIF still matches our keep list — same Apple, same iPhone 16 Pro — so it stays visible. iOS does not write a unique device identifier like a serial number in the photo metadata, and the software field only tells us something like the iOS version or editing app, not which physical phone took the shot. That's good for privacy, but make and model are as far as the metadata gets us. For most libraries, this is probably a handful of images, not hundreds.

When there's no metadata at all

Screenshots, downloaded images, and a lot of things saved from messaging apps have no camera make or model in the file itself. Early on we built a metadata inspector and tried to answer a harder question: not just "what camera took this?" but "where did this come from?"

The Apple Photos app can answer that sometimes. Tap the info panel on a photo you saved and Photos might show "Saved from Instagram" or something similar. But that label is not in the photo's EXIF data. It is part of Photos' own record of the import: iOS knows which app handed the file to the library, stores that in metadata only Photos has access to, and then uses it when Photos renders the info panel.

Third-party apps don't get that same view. PhotoKit's public API stops at standard EXIF, QuickTime tags, and a few asset subtypes (such as screenshots). Pull the file through ImageIO and we see camera make/model, or nothing — not "Saved from Reddit."

So MyOriginals treats "no EXIF camera data" as not captured by our devices and marks it to hide. Where PhotoKit does expose type — screenshots via asset subtypes, screen recordings by dimensions — we use that too. But for a saved meme or a photo someone AirDropped us, if the file doesn't carry our camera's make and model, we can't confirm we captured it.

The entire write surface is two lines

Here's the part we care about most. People are right to be wary of an app that asks for full photo library access and then starts moving things around. So we kept the write surface as small as it can possibly be.

MyOriginals never deletes. It cannot delete — there is no call to deleteAssets anywhere in the codebase, and no delete button in the app. The only mutations the app performs against our libraries are these two:

// hide
let request = PHAssetChangeRequest(for: asset)
request.isHidden = true

// unhide
let request = PHAssetChangeRequest(for: asset)
request.isHidden = false

That's it. isHidden = true and isHidden = false. Hiding just sets a flag PhotoKit already supports; the asset moves into the system Hidden album that iOS has shipped for years. A photo in our Vacation album is still in that album while hidden — it just won't show in the main grid. Unhide it and it's exactly where it was.

Because the only operations are reversible by construction, undo is trivial: every hide is recorded, so we can undo the last one, browse recently hidden items, or unhide everything at once. The app keeps a log of the last 100 operations so we can always see what it did and when.

That's the whole app — read metadata, set a flag, undo if we got it wrong. Built for the moment when we want to show someone one photo without exposing the rest of the camera roll.