#stringify Everything

An expression has a value. It also has a story.

Apple's #stringify example keeps the two together. Give the example macro a + b, and the expanded code carries both the result and the source text that produced it. The number tells me what happened. The expression gives me somewhere to start asking why.

// Illustrative: using a stringify macro like Apple's example.
let (value, source) = #stringify(a + b)
// value: 3, source: "a + b" when a = 1 and b = 2

Before and after

Say a profile screen has a person.name property. Without a macro, a developer can pair its value with a label by hand:

let value = person.name
let source = "person.name"

That works, but the label can become stale if someone changes the expression and forgets to update the string. With a #stringify macro declared in the project, the compiler expands this call into a value and the expression’s source text:

let (value, source) = #stringify(person.name)
// value: "Anupam"; source: "person.name"

The expression is evaluated at runtime; the source is captured during compilation. The macro does not automatically track dependencies or explain why a name has its value. Avoid recording sensitive values without a clear reason and safeguards.

A string catalog has a different job. It can hold a translated label like “Profile” or “Profil”; the name itself remains data. An app chooses where to combine the localized label and the value. A model might suggest a description of a screen, but the app must connect these pieces and check the suggestion.

I keep coming back to that pairing when I think about apps and the agents inside them. A trip plan, a trading explanation, or a task sent to another Mac has a result. It also has choices behind it. Which tools were available? What did the person ask for? Which parts are suggestions and which parts can actually run?

#stringify doesn't answer those questions by itself. It gives me a useful starting point: keep the thing and enough context to explain the thing.

A plan before an action

Imagine an app that helps two people plan a day. One wants to drop off laundry. The other wants to pick it up before dinner. A model might suggest an order for the tasks. The app still needs to know whether those tasks exist, whether the timing makes sense, and whether anyone approved a booking.

// Concept, not an existing API.
let proposal = planner.suggest(request)
let checked = rules.validate(proposal, against: availableTools)
show(checked)

The proposal is data. Validation belongs to code. The screen should say which tools were used and what still needs a person's decision. If the weather tool is off, the app should say so rather than invent a forecast.

I like this boundary because it makes the software easier to inspect. The model can help with language and ideas. A typed plan gives the rest of the app something concrete to check. An approval belongs to a particular action, not to a friendly paragraph that happens to mention one.

From words to a shape

Apple's Foundation Models framework has a way to ask for a Swift-shaped answer. Mark a structure @Generable and the model can generate an instance of it. @Guide can describe fields or constrain some generated values. A trip app might ask for a proposed title and a list of stops:

// Illustrative shape; validation and availability handling are omitted.
@Generable
struct DayPlan {
    @Guide(description: "A short title for the day")
    var title: String
    var stops: [String]
}

The shape helps the rest of the program consume the answer. It doesn't prove that a stop exists, that a shop is open, or that the person wants to book anything. Those checks still belong outside the model.

Sometimes the model needs a fact from the app. A Foundation Models Tool describes an operation, accepts structured arguments, and runs Swift code in call(arguments:). Its result can be represented as a prompt so the model can use it in a subsequent response. A read-only saved-places lookup is a reasonable first tool. It can return “not found” just as honestly as it returns a place.

PromptRepresentable is the bridge for a value that can be presented as part of a prompt. Apple says @Generable provides this conformance automatically and warns against overriding it. For a type that isn't Generable, you can provide a representation yourself. Either way, decide which fields the model actually needs before placing personal information into context.

There is another boundary worth naming: MCP is a protocol for exposing tools, resources and prompts to an AI application. A Foundation Models Tool is a Swift interface for code the model can call. They can be connected through an adapter, but one does not automatically become the other. An adapter would need to map inputs, results and errors, and retain the same permission checks as the underlying operation.

The words on the screen

The same idea reaches the small labels we tend to forget. A plan can have a well-defined state and still be confusing if its button says “Continue” when it will place a booking. Name the action. Explain the result.

Apple's string catalogs give those words a place to live. Xcode can collect strings passed through localizable APIs when a project builds. A catalog can hold translations, plural forms and device-specific variants. It can also carry comments that explain what a phrase means to someone translating it.

The catalog does not translate an interface correctly just because it exists. A runtime String needs the appropriate localization API, and a sentence assembled from fragments can be difficult to translate. Review the text in context. Run the app in the languages and layouts it supports. A long German button and a right-to-left screen will tell you things a source file cannot.

I wouldn't put Swift source code into a translation catalog just because #stringify can produce a string. Source is evidence for a developer. A catalog entry is language for a person using the app. They may meet on the same screen, but they have different jobs.

Give the agent a small set of hands

An agent that can read a saved place, ask for a route and check weather doesn't need the power to do everything else on the phone. Each capability can have a name, inputs, a result and a way to report failure. If an action can send, buy or change something, the app can show the exact request and ask the person to approve it.

That is useful for a team of Macs too. One machine can report its status. Another might be a good place to run a task. The interesting part is showing why that suggestion was made, then reporting the actual result. Having the Macs speak those lines is a direction I'm exploring; it doesn't make the handoff verified.

In Appify, a StringifyMacro implementation constructs a value with the expression's trimmed source alongside it. There are also typed manifest structures. Those pieces are promising ingredients for experiments with previews and receipts. They are not proof that a complete planner, localization pipeline, or cross-device workflow works today.

What I want to try next

Start with one small plan. Show its typed tasks beside a readable explanation, keep the original request, and let the person turn a tool off. Then test the uncomfortable cases: a missing place, an unavailable tool, an old result, a translated label that no longer fits. Only after that would I add an action that changes something, with a specific approval and a result the person can inspect.

The title started as a joke. I still don't want to stringify everything. I do want the parts that matter to leave a trail.

---

Research notes: Apple: Expand on Swift macros, Apple: Generable, Apple: Tool, Apple: PromptRepresentable, Apple: Localizing and varying text with a string catalog, MCP: Understanding servers.