agentsclimarketplace

Typography

Skill rshankras/claude-code-apple-skills/skills/design/typography

UI typography on Apple platforms — text styles and Dynamic Type, the San Francisco family (Pro/Rounded/Compact/Mono/New York + width axis), optical sizes, tracking vs kerning, leading adjustments, and custom-font scaling. Use when choosing fonts, building type hierarchy, fixing truncation/legibility, or making custom fonts respect Dynamic Type.From its SKILL.md

Install
npx -y skills add rshankras/claude-code-apple-skills --skill typography

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

6.5 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Typography

Type is most of your UI. The system does the hard parts — optical sizes, tracking tables, Dynamic Type — if you use its APIs. This skill covers when to trust the system, how to build hierarchy deliberately, and what custom fonts owe you back.

When This Skill Activates

  • Choosing fonts or building a type hierarchy for a screen or app
  • Text truncating, cramping, or breaking under larger Dynamic Type sizes
  • Adopting a custom/brand font (and keeping accessibility)
  • Display typesetting: hero numbers, stats, editorial headlines

Rule 1: text styles first

Predefined styles (Large Title → Caption 2) are weight + size + leading combos with Dynamic Type support built in — and different styles scale differently (body grows more than footnote), which manual font sizes can't replicate.

  • Build hierarchy from 2–3 text styles + emphasized variants (bold trait — the actual weight varies per style: some go medium→semibold, others bold→heavy) before reaching for new fonts.
  • Semantic colors + text styles together give dark mode, contrast, and Dynamic Type for free.
  • macOS supports text styles (without Dynamic Type); design Mac type at 100% — no iOS-style scaling assumptions.

Rule 2: let optical sizes and tracking work

  • San Francisco blends Text→Display designs continuously between 17 and 28pt (below: sturdier letterforms, looser tracking for legibility; above: tighter, more refined). System font APIs do this automatically — hardcoded single-cut fonts don't.
  • Tracking, not kerning, for letterspacing — tracking is size-specific and lets the OS disable clashing features (ligatures). Override system tracking only in exceptional cases.
  • Truncation pressure? Use allowsTightening (default-tightening-for-truncation) instead of manually squeezing — and prefer wrapping to truncating (line limit 0 on labels that matter).
  • Line height moves only via leading traits: tight = −2pt, loose = +2pt (±1pt on watchOS); the system adds leading automatically for tall scripts (Arabic, Devanagari).

The Dynamic Type ladder (WWDC24 10074)

12 sizes: 7 default + 5 accessibility (AX1–AX5). .body runs 17pt at default up to 53pt at AX5 — roughly 3× taller, and layouts must expect that. Escalate in order:

  1. Text styles.font(.title) / preferredFont(forTextStyle:) + adjusts-for-content-size, line count 0 so text wraps instead of truncating.
  2. @ScaledMetric for the non-text riding alongside (icon frames, spacing); SF Symbols scale via UIImage.SymbolConfiguration(textStyle:). Prioritize scaling essential content over decoration.
  3. Switch layout axis at accessibility sizes — branch on dynamicTypeSize.isAccessibilitySize with AnyLayout(HStackLayout()) / AnyLayout(VStackLayout()) (UIKit: flip the stack axis on preferredContentSizeCategory.isAccessibilityCategory); give text the full line width and relax lineLimit.
  4. Large Content Viewer — only for bars that legitimately can't grow: a tab bar takes under 10% of screen height, and scaled to accessibility sizes it would eat almost a quarter (WWDC24 10074). Scaling is always preferred; the viewer is the fallback, not the fix.

Test at all 12 sizes (Xcode Previews → Variants → Dynamic Type Variants), not just the biggest — mid-range accessibility sizes catch different wrap points.

The San Francisco family — pick by job

FaceJob
SF ProThe default; UI text everywhere
SF Pro RoundedFriendlier numerals/labels — widgets, health/fitness data
SF CompactwatchOS (space-efficient counterpart)
SF MonoCode, tabular alignment
New YorkSerif — reading experiences, editorial contrast
SF Arabic / SF Arabic RoundedArabic script with its own optical sizes

The width axis (Condensed / Regular / Compressed / Expanded):

  • Default Regular; every non-Regular choice is a legibility decision — check it.
  • Condensed: fit more text comfortably (long headlines wrap one line fewer).
  • Compressed: display-only density, not body text.
  • Expanded: display typesetting AND small secondary labels (wide + loose tracking).
  • Width is a fourth hierarchy lever beside weight, size, color; all widths share identical vertical proportions, so mixing them never misaligns baselines. 2–3 styles are enough — pair one width with contrasting weights, one weight with contrasting widths, or oppose both for maximum display contrast.

Custom fonts: what you owe back

System fonts get Dynamic Type free; a brand font makes you the type engine:

  • Scale with UIFontMetrics(forTextStyle:).scaledFont(for:) + adjusts-for-content-size, or SwiftUI Font.custom(_:size:relativeTo:); scale layout constants with @ScaledMetric.
  • Test at the largest accessibility sizes — wrap to multiple lines rather than truncate.
  • Verify script coverage for your locales; have a fallback plan for writing systems the brand font doesn't cover (the system stacks: system-ui, ui-rounded, ui-serif, ui-monospace on the web).
  • Budget for the maintenance: tracking tables, optical sizing, and weight ramps are things SF does that a licensed font usually doesn't.

❌ Anti-patterns: hardcoded point sizes on user-facing text · kerning APIs for tracking jobs · custom font without relativeTo: (frozen size) · Compressed body text · truncation where wrapping was possible.

Output Format

Type review: Element | Current (font/size/style) | Issue (hierarchy/scaling/legibility) | Fix — check Dynamic Type at XXL + AX sizes before signing off; pairs with the contrast rules in generators/accessibility-generator.

References

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most design systems skills give in ~1.4k tokens

Counted across 501 of the 520 authors here whose files we hold, read 2026-09-06

  • Extract colors, typography, spacing, radii, shadows, breakpointsin 20 of 501, across 10 files
  • Create a self-contained dependency-free HTML preview pagein 20 of 501, across 10 files
  • Keep touch targets at least 44x44pxin 20 of 501
  • Score the UI across ten dimensionsin 18 of 501, across 8 files
  • Animate exclusively via transform and opacityin 18 of 501, across 15 files
  • Ensure WCAG AA color contrastin 18 of 501, across 13 files
  • Generate DESIGN.md with rationale for each decisionin 17 of 501, across 7 files
  • Ensure proper contrast and readabilityin 15 of 501, across 10 files
  • Scan the codebase for existing style patternsin 15 of 501, across 6 files
  • Give every interactive element a visible focus indicatorin 15 of 501, across 13 files
  • Propose a design token setin 14 of 501, across 5 files
  • Create a custom theme when none fitin 14 of 501, across 9 files

Said here and by no other author read

  • Build hierarchy from text styles before custom fonts
  • Use tracking, not kerning, for letterspacing
  • Prefer wrapping to truncating with line limit zero
  • Adjust line height only via leading traits
  • Use allowsTightening instead of manual squeezing
  • Scale non-text layout with @ScaledMetric

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.