Dynamic Type is a layout requirement as much as a font choice. A scalable font inside a fixed-height container can still clip at accessibility sizes.
- 1Semantic text style
- 2Scaled content
- 3Flexible layout
- 4Largest-size check
Work through the example
Test the longest label at the largest supported text setting. Prefer wrapping or a changed layout to shrinking meaningful text.
Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.
Implementation reference
The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.
5. Dynamic Type Support
@ScaledMetric
Scale arbitrary numeric values proportionally to the user's Dynamic Type setting.
struct ScaledMetricDemo: View {
@ScaledMetric(relativeTo: .title) var iconSize: CGFloat = 28
@ScaledMetric(relativeTo: .body) var spacing: CGFloat = 12
@ScaledMetric(relativeTo: .body) var cardPadding: CGFloat = 16
var body: some View {
HStack(spacing: spacing) {
Image(systemName: "person.circle.fill")
.font(.system(size: iconSize))
.foregroundStyle(.blue)
VStack(alignment: .leading, spacing: 4) {
Text("John Appleseed")
.font(.headline)
Text("iOS Developer")
.font(.subheadline)
.foregroundStyle(.secondary)
}
}
.padding(cardPadding)
.background(Color(.secondarySystemBackground))
.cornerRadius(16)
}
}
minimumScaleFactor
Prevent text from being clipped while still supporting Dynamic Type.
struct ScaleFactorDemo: View {
var body: some View {
Text("This very long title will shrink instead of truncating")
.font(.title)
.minimumScaleFactor(0.5)
.lineLimit(1)
.padding()
}
}
Acceptance and failure review
| Checkpoint | What to inspect | If it does not match |
|---|---|---|
| Semantic text style | Confirm the input and environment | Preserve the failure and return to this step |
| Scaled content | Inspect the intermediate artifact | Preserve the failure and return to this step |
| Flexible layout | Run the focused check | Preserve the failure and return to this step |
| Largest-size check | Record the observed result | Preserve the failure and return to this step |
Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.
Evidence and limits
Source examples are guidance; screenshots and VoiceOver checks must come from the actual app.
This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.
Inspect the source used in this lesson.
Related reading
- Five checks for an AI-built SwiftUI app
Use persistence, search and accessible states to make “it works” a testable claim.
What to do next
Next: Motion and haptics: what to ask an agent for, and what reduced-motion users need