Skip to content
fitme·story
Case studies
v7.8.3 · 1 min read · 2026-05-12

iOS UI-Audit P1 Drift Cleanup — 44 → 14 (Option B Respected, 68% Reduction)

Drift-cleanup follow-up to `ios-ui-audit-p1-burndown` (PRs #292+#294). Respects Option B's locked ceiling — tokenizes ONLY magic dims with frequency >= 2 across the iOS codebase. Result: ui-audit P1 44 → 14 (-68%), DS-MAGIC-FRAME 40 → 12, DS-MAGIC-PADDING 4 → 0. The 14 remaining are true singletons that stay as fix-as-you-touch per the parent feature's locked decision. 10 new AppSize tokens + 4 magic-padding swaps. Single PR, single session.

After parent burndown
44 P1
Where ios-ui-audit-p1-burndown (PRs #292 + #294) left the surface — 40 DS-MAGIC-FRAME + 4 DS-MAGIC-PADDING.
After drift cleanup (#307)
14 P1
10 new AppSize tokens (frequency ≥ 2 only) + 4 magic-padding swaps; DS-MAGIC-PADDING to 0. The 14 remaining are true singletons kept as fix-as-you-touch per Option B.
What do T1 / T2 / T3 mean?
T1Instrumented — from a ledger/commit
T2Declared — stated, not measured
T3Narrative — estimate from memory

Overview

Drift cleanup on the iOS make ui-audit P1 surface. The parent feature ios-ui-audit-p1-burndown locked Option B ("high-frequency tokens only; long-tail singletons stay as fix-as-you-touch") and shipped 103 → 44. This follow-up applies the same rule (frequency ≥ 2 only) to push 44 → 14.

What shipped

10 new AppSize tokens in FitTracker/Services/AppTheme.swift:

TokenValueOccurrences
indicatorDotTiny67
chartHeightTall2005
progressBarHeightTall63
chartHeightCompact1802
chartMinWidth2602
iconJumbo962
avatarHero722
illustrationLarge1202
illustrationXLarge1602
controlSmall342

4 magic-padding fixes swap off-grid values to nearest AppSpacing token (1-2pt shift, all on the 4pt grid).

What stays deferred

14 true singletons remain. Per Option B, adding a token for each would bloat the design system without improving coherence.

Honest framing

This was a continuation of the parent feature's discipline, not a bulldoze. Option B respected.

Honest disclosures
  • This was a deliberate scope-locked enhancement, not a bulldoze. The user could have asked me to push past Option B's ceiling to 0; I surfaced the contradiction with the parent's locked decision and we agreed to respect it. The frequency-≥-2 rule produced a defensible 68% reduction without violating the parent's "high-frequency tokens only" rationale.
  • The 14 remaining P1s are true singletons. Adding a token for each (50, 76, 88, 60, 58, 320, 30, 280, 220, 150, 140, 14, 0.5) would bloat AppSize without improving design coherence.