tidy.

Apple's on-device model takes no images. I measured what that rules out

A customer asked for a refund last week. He does web development, downloads a batch of images for a client, and used to rename them by hand. He wanted my app to look at a photo of a chair and call it walnut-dining-chair.jpg. Mine reads the text written inside a file, so on a photo of a chair it has nothing to read and does nothing at all. Fair enough. I refunded him and went to find out whether what he wanted was possible on a Mac without the photo leaving it.

It is not. Here is exactly why, and what I got when I tried anyway.

Foundation Models is text-only, and the type system says so out loud

Apple's on-device language model, the one you get with SystemLanguageModel on macOS 26, takes a transcript made of segments. There are two kinds:

public enum Segment : Swift.Sendable, Swift.Identifiable, Swift.Equatable {
    case text(FoundationModels.Transcript.TextSegment)
    case structure(FoundationModels.Transcript.StructuredSegment)
}

That is the whole set. There is no image case, no attachment, no multimodal anything. Grep the framework's Swift interface for CGImage, NSImage or UIImage and you get zero hits:

cd "$(xcrun --show-sdk-path)/System/Library/Frameworks/FoundationModels.framework"
cd Versions/A/Modules/FoundationModels.swiftmodule

grep -c "CGImage\|NSImage\|UIImage" arm64e-apple-macos.swiftinterface
# 0

This is not a limitation you discover at runtime or a capability gated behind a flag. You cannot express the request. Whatever you want the model to know about a picture, you have to describe in words first, and then you are back to needing something that can look at pictures.

Vision has 32 request types and not one of them describes anything

The obvious candidate for that "something" is Vision. I listed every request type in the macOS 26 SDK. There are thirty-two. They detect faces, hands, animal poses, barcodes, contours, horizons, rectangles, lens smudges, trajectories. They generate saliency maps, segmentation masks, feature prints. They track things. Two of them are close to what I wanted:

• RecognizeTextRequest, which reads text that is written in the image. This is what my app already runs on.
• ClassifyImageRequest, which returns labels from a fixed vocabulary with confidence scores.

Classification is not description. It hands you a bag of nouns from a list Apple decided in advance, with no relationships between them and no sense of what the picture is for. "Chair" and "wood" and "indoor" is not walnut-dining-chair. But it is what exists, so I built it and measured it instead of guessing.

25 photos from my own machine

Not a benchmark set. My actual photos, which is the only test that matters for a file organizer. I took the top labels above 0.70 confidence, capped at three, and composed a filename.

Result	Count
Photos that produced any name at all	14 of 25
Of those, names that were the word "document"	9
Surviving a filter that drops useless labels	2 of 25
Of those two, ones I would actually keep	0

Nine of fourteen proposals came back as some variation of "document" or "screenshot", which for a tool whose entire job is telling files apart is worse than useless. It is confidently wrong in a way that makes every file look identical. Once I filtered the empty labels out, two names survived out of twenty-five, and both were the kind of guess I would have deleted by hand.

I want to be precise about what that number means, because it is easy to over-read. It does not mean Apple's classifier is bad. It means classification answers a different question than the one a filename asks. A filename is not a description of pixels, it is a description of why you kept this, and no model that has never met you can produce that from the image alone. Brett Terpstra put it better than I did when he tried the app: OCR captures what a file says, not what it means to you. He was talking about text and he was already right. It is twice as true for pictures.

So what are the apps that promise this actually doing?

There is a whole category of these now, and several of them advertise naming your images from their visual content. Given the above, on a Mac there are only two ways to do it, and both are worth knowing about before you point one at a folder of client work:

• The picture leaves your machine. It goes to a vision model on someone's server, which does describe images, and does it well. This is the common one. It is also the one that matters if the folder contains invoices, medical records, or anything under an NDA.
• The app ships its own model. A few bundle a local vision-language model rather than using Apple's frameworks. That genuinely stays on your machine. It also means downloading gigabytes and paying for it in RAM and battery, and it is a different engineering commitment than calling a system API.

Neither is dishonest by itself. What is worth checking is which one you bought, because "runs locally" and "runs on-device using the frameworks that came with your Mac" are being used to mean the same thing and they are not the same thing at all.

Check it yourself

Everything above is one command away if you have Xcode installed. The Swift interface files are plain text and they are the actual contract, not documentation that might be stale:

cd "$(xcrun --show-sdk-path)/System/Library/Frameworks/FoundationModels.framework"
cd Versions/A/Modules/FoundationModels.swiftmodule

grep -A3 "public enum Segment" arm64e-apple-macos.swiftinterface

If that ever prints a third case, I would like to know. And to count the Vision requests yourself:

cd "$(xcrun --show-sdk-path)/System/Library/Frameworks/Vision.framework"
cd Versions/A/Modules/Vision.swiftmodule

grep -oE "(struct|class) [A-Za-z]*Request\b" arm64e-apple-macos.swiftinterface \
  | sed 's/^[a-z]* //' | sort -u

---

I make Tidy, a Mac menu bar app that reads what is written inside your files and names them from that. It does not describe photos, for the reasons above. $9 once, macOS 14 and up, everything runs on your machine. I answer my own email at hola@tidymacapp.com.