ultrapolish-ios

Universal polish for native Swift/SwiftUI apps. Any app, its own style, from 6/10 to 11/10 on detail, UX, and cohesion.

This is not a visual style. It is a craft standard and a procedure. It works with cream-and-serif, with true-black-and-mono, with system-default blue. It makes what is already there feel considered, continuous, and alive.

0. The universality guard

Read this before touching a pixel.

1. Read before you write. Find the project's own rules: DESIGN.md, AGENTS.md, CLAUDE.md design sections, a DesignSystem.swift, Theme, Tokens, Motion, Haptics files, asset catalog colours, existing springs, radii, and spacing constants. Grep for cornerRadius, .spring(, .snappy(, .padding(, sensoryFeedback, Font.. Build the intake table (section 1) before proposing anything.
2. Never introduce what the project does not have. No new typeface, no new palette, no new radius language, no new motion personality. If the app is flat and sharp, polish it flat and sharp. If it is warm and rounded, polish it warm and rounded.
3. Numbers here are defaults for projects without an established value. The project's own constant wins whenever it is used consistently. Inconsistency is the finding; the value is not.
4. The anti-pattern list is a negative list. It says what reads as generic or careless. It does not imply a positive style.
5. No system? Propose one before polishing. Offer the 15-line design contract from references/design-contract-template.md, get it agreed, then work inside it. Polishing without a contract produces a second, competing style.
6. Restraint is a deliverable. The right change is often "remove", "align", or "reuse". Every finding must name what the user gains. If you cannot, it is not a finding.

1. Workflow