How deep can @Generable nest?

The question began with an outfit card. Could a model fill the same information if I organized the Swift type differently?

The original demo showed four cards at once: flat, two levels, four levels, and four levels with guides. Each card carried an outfit, a token count, a time, and a row of green checks. It was a lot to read before the question had landed.

The question is simpler: does grouping the same information change the answer?

One request, two shapes

Imagine asking for a rainy-day outfit: a jacket, shoes, and a short reason. A flat type keeps those fields together:

@Generable
struct Outfit {
    var jacket: String
    var shoes: String
    var reason: String
}

A nested type groups the clothing separately:

@Generable
struct Outfit {
    var clothing: Clothing
    var reason: String
}

@Generable
struct Clothing {
    var jacket: String
    var shoes: String
}

Both describe an outfit. The second has another layer. This example explains the shapes; it is not the exact input or schema used for the recorded evaluation.

What the experiment actually measured

The original evaluation used a fictional desk note with known answers. It compared six variants of a 16-field result on one Mac and one on-device model: flat, two, three and four levels, four with guides, and a split across two calls. Five notes ran five times per variant. The article draft recorded a 100% parse rate across those variants; complete field accuracy differed by variant.

Here are the results from that run. “All fields right” means the entire 16-field answer matched the known key; field accuracy counts the individual correct fields.

Schema	All fields right	Field accuracy	Parsed
Flat	23/25	97.75%	25/25
Two levels	23/25	99.5%	25/25
Three levels	20/25	98.75%	25/25
Four levels	20/25	98.75%	25/25
Four levels + guides	25/25	100%	25/25
Four levels, split into two calls	20/25	98.75%	25/25

The deeper unguided versions had fewer completely correct answers in this run, but that is not proof that nesting caused the difference. There were only five distinct notes, repeated five times each, on one model and one Mac. One note accounted for repeated mistakes. Guides changed more than depth, and the experiment did not test a guide on that field alone.

To evaluate an app's own schema, make a set of representative inputs with known answers, run each schema against the same inputs multiple times, and compare parse failures, individual field accuracy and fully correct answers. Record model and OS versions, prompts, schema, sampling settings, latency and failures; inspect mistakes per input rather than relying only on averages. Add more diverse cases and repeat the experiment before drawing conclusions about depth. The creative outfit demo cannot measure factual accuracy this way without a defined answer key.

There is a difference between a response fitting its type and the values inside it being right. A valid card can still carry the wrong indicator or timeframe. An enum can constrain a choice while the model chooses the wrong valid case.

The outfit demo was a different check

Here is the original four-card Mac demo. The recording shows the earlier design, not the newer side-by-side prototype described above.

The Mac demo asked for a creative outfit and compared 14 fields across four schema arrangements. A creative outfit has no single correct answer. Its five checks looked for things code could check, such as missing fields, word limits and whether a requested quote appeared. Those green badges were not a verdict on the outfit's quality.

The earlier run recorded three real on-device comparisons and light and dark screenshots. The test target checks the grading functions without calling the model. I haven't rerun the app or those model sessions for this article.

What I would take from this

The original demo displayed “keep to four levels” and “prefer two” as a rule. The experiment does not support a universal limit. Four levels and 16 fields were the boundary of this particular evaluation, not the point at which nesting fails.

Use the shape that makes your data understandable. Add guidance where the output needs it. Then test the exact prompts, data and devices your app uses. A small set of repeatable cases can reveal a mistake that a perfectly valid type won't.

A structure can make an answer easier to use. It cannot make the answer true.

Apple's guided generation documentation explains the API. The results above describe one local experiment, not an Apple guarantee.