Designs tasteful iOS 18+ SwiftUI experiences from user goals and context. For building views, screens, or reviewing SwiftUI design quality.
npx claudepluginhub joshuarweaver/cascade-code-general-misc-1 --plugin pproenca-dot-skills-1This skill uses the workspace's default tool permissions.
Taste doesn't start at the pixel level. It starts at "who is this
Applies Acme Corporation brand guidelines including colors, fonts, layouts, and messaging to generated PowerPoint, Excel, and PDF documents.
Builds DCF models with sensitivity analysis, Monte Carlo simulations, and scenario planning for investment valuation and risk assessment.
Calculates profitability (ROE, margins), liquidity (current ratio), leverage, efficiency, and valuation (P/E, EV/EBITDA) ratios from financial statements in CSV, JSON, text, or Excel for investment analysis.
Taste doesn't start at the pixel level. It starts at "who is this person and what do they need?" The visual refinement is the LAST step. The first step is understanding the user's world deeply enough that the interface design feels inevitable — like it couldn't have been designed any other way.
Your default mode skips straight to layout. It produces technically correct SwiftUI that looks generic because it was never grounded in a real person's needs. This skill changes the order of operations: think like a designer first, then write code.
Before designing anything, answer ONE question:
What does the user SEE in the first half-second — before they read a single word?
This is not about content. It's about the SHAPE of the screen. Close your eyes and picture it. What dominates?
If your answer is "a List with rows of text" → STOP. That's a spreadsheet, not an app. Go back and find the visual shape.
Write the 0.5-second answer as the FIRST line of the experience brief:
// 0.5s: Four warm gradient cards stacked on black — a cookbook
This single sentence anchors every decision that follows. If the code you write doesn't produce that shape, something went wrong.
Before writing a single line of code, answer these questions. Write the answers down as comments or in your thinking. If you skip this phase, your output will look like every other AI-generated UI — correct but soulless.
Not "a fitness enthusiast." A real person with a context:
This shapes EVERYTHING. A user mid-workout needs giant tap targets and glanceable data. A user browsing recipes at home wants rich detail and discovery. A user configuring settings wants to find the one toggle they care about and leave.
This is the question that separates designed apps from information displays. Apple Fitness doesn't show you data — it motivates you to move. Every design choice serves that emotional goal.
Before choosing components, decide the emotional intent:
The emotional intent drives every visual decision downstream: color palette, scale, spacing, whether data is listed or visualized, whether the screen feels dense or spacious.
For each screen, identify:
A fitness settings screen: the primary goal isn't "see all settings." It's "change the one thing that's been bugging me" — maybe the weekly goal is too low, or notifications come at the wrong time. The pain point is wading through 30 options to find the one they need.
Map goals to features. Not "what features could this screen have?" but "what's the minimum set of features that makes the primary goal effortless?" Every feature that doesn't serve a goal is clutter.
Group features by priority:
This is information architecture — deciding what goes where:
NOW you think about SwiftUI — but through the lens of user intent:
The component choice IS the design. A slider for a weekly workout goal feels exploratory and forgiving. A stepper for the same value feels precise and clinical. Neither is wrong — the right choice depends on who the user is and what moment they're in.
After Phase 1, you know who the user is, what they need, how they should feel, and what components serve those needs. Now make it beautiful. The emotional intent from Phase 1 drives every choice here.
Not just font weight — dramatic scale contrast. The most important thing on screen should be physically large, not just bold.
.system(size: 64) or
.largeTitle with .fontDesign(.rounded). Apple Fitness shows
"120" as 40% of the screen. Don't shrink important data into a row..caption or .footnote in .secondary. The
contrast between the hero and the support IS the hierarchy.NEVER pick colors by hand. Color harmony is a solved mathematical problem. This skill bundles a palette generator that computes every color from a single seed hue — analogous harmony, WCAG contrast validated, light and dark mode variants.
Before writing any view code, run the palette generator:
python scripts/generate_palette.py \
--seed <hue-degrees> \
--mode both \
--items <collection-count> \
--app "App Name"
Seed hue guide:
Include the generated enum Palette { ... } at the top of your
Swift file and use ONLY those colors. The palette is computed —
every color is mathematically related to the seed, contrast ratios
are pre-validated, and light/dark mode variants are included.
Rules that never break:
--items flag),
not random hues. They sit together because they're ±30° of seed.Color.red, .green, .blue as palette colors —
those are semantic system colors for status indicators.Palette.primary, Palette.cardBackground, etc. — not
ad-hoc Color(hue:) calls scattered through the view code.When data is the content (fitness metrics, financial stats, progress), VISUALIZE it instead of putting it in a label:
A LabeledContent("Steps", value: "8,432") is information. A large
"8,432" in .title with a sparkline below it is an experience.
The emotional intent from Phase 1 tells you which one to use.
Don't default to .insetGrouped List for everything. Compose with
rounded rect containers when the content is heterogeneous:
RoundedRectangle(cornerRadius: 16) and
.fill(.secondary.opacity(0.15)) on dark backgroundsLazyVGrid or LazyVStack inside a ScrollView for
card-based layoutsLists are for homogeneous rows (contacts, messages, settings). Cards are for dashboards, summaries, and content-rich screens.
The data IS the design. Every preview tells a coherent story:
What you leave out defines taste. No instruction headers. No uniform icons. No tutorial overlays. No demo naming. For every element, ask: "what happens if I remove this?" If nothing — remove it.
The invisible details that feel right:
.monospacedDigit() on changing numbers@ScaledMetric on custom sizes.contentTransition(.numericText()) on counters.sensoryFeedback() on meaningful state changes (not haptic spam)LabeledContent for key-value pairsEach screen has a distinct personality. Character comes from:
When asked to build a SwiftUI view:
Phase 1 — Think through the user, their goals, feature groupings, screen structure, and component choices. Write brief notes (as code comments or in your response) showing your design reasoning. This is not optional — it's what separates a designed experience from a decorated layout.
Phase 2 — Write the SwiftUI code with all five fundamentals applied. Start with realistic data models and preview content. Build minimal, add only what earns its place, then polish with craft details.
Self-check — Before finishing, ask: "Would a real user using this app in the moment I identified in Phase 1 feel like this screen was designed for them?" If not, something in Phase 1 was wrong — go back.
// NO TASTE — jumped straight to layout, no user thinking
struct DemoView: View {
var body: some View {
NavigationStack {
List {
Section("Instructions") {
Text("This demo shows how lists work")
}
Section("Items") {
ForEach(1...5, id: \.self) { i in
HStack {
Image(systemName: "star")
Text("Item \(i)")
Spacer()
Text("Detail")
.foregroundStyle(.secondary)
}
}
}
}
.navigationTitle("Demo")
}
}
}
No user thinking. No goals. Instruction header. Uniform icons. Numbered placeholders. Generic naming. No character.
// GOLDEN — Weather-inspired fitness dashboard
// User: Alex, 28, just finished a morning run, wants to see today's stats
// Emotional intent: MOTIVATED — celebrate the effort, inspire tomorrow
// Hero: calorie ring dominating the top half
struct FitnessCardView: View {
let calories: Int = 847
let goal: Int = 1000
var body: some View {
ScrollView {
VStack(spacing: 20) {
// Hero ring — 40% of visible screen, not a row in a list
ZStack {
Circle()
.stroke(.quaternary, lineWidth: 20)
Circle()
.trim(from: 0, to: Double(calories) / Double(goal))
.stroke(calorieGradient, style: StrokeStyle(lineWidth: 20, lineCap: .round))
.rotationEffect(.degrees(-90))
VStack(spacing: 4) {
Text("\(calories)")
.font(.system(size: 56, weight: .bold, design: .rounded))
Text("of \(goal) cal")
.font(.subheadline)
.foregroundStyle(.secondary)
}
}
.frame(width: 220, height: 220)
.padding(.top, 20)
// Stat cards — NOT LabeledContent rows
HStack(spacing: 12) {
statCard("Distance", value: "5.2 km", color: .blue)
statCard("Time", value: "28:14", color: .green)
statCard("Pace", value: "5'26\"", color: .orange)
}
}
.padding()
}
}
private func statCard(_ label: String, value: String, color: Color) -> some View {
VStack(spacing: 6) {
Text(value)
.font(.system(.title3, design: .rounded))
.fontWeight(.semibold)
Text(label)
.font(.caption)
.foregroundStyle(.secondary)
}
.frame(maxWidth: .infinity)
.padding(.vertical, 16)
.background(color.opacity(0.1), in: .rect(cornerRadius: 12))
}
private var calorieGradient: AngularGradient {
AngularGradient(colors: [.red, .orange, .yellow], center: .center)
}
}
Design comment explains user moment and emotional intent. Hero ring dominates the screen (not a ProgressView in a List row). Stat cards use color backgrounds, not LabeledContent. You know this is a fitness app without reading the title — the ring IS the identity.
When you instinctively reach for a tutorial component, STOP:
| NEVER (reflex) | GOLDEN (reach for this instead) |
|---|---|
List + ForEach | ScrollView + LazyVStack with cards |
Form + Section | ScrollView + GroupBox(.regularMaterial) |
LabeledContent for metrics | Hero typography .system(size:design:.rounded) |
ProgressView | Circle().trim(from:to:) or Canvas |
Button("Label") | .borderedProminent + .controlSize(.large) |
Toggle in Section | Segmented control or custom pill |
.system(size:) for text | .largeTitle / .title + .fontDesign(.rounded) |
Default List background | Gradients, .regularMaterial, colored containers |
Modern iOS 18+ APIs to reach for: MeshGradient, .scrollTransition,
.containerRelativeFrame, .visualEffect, Canvas, TimelineView,
.scrollTargetBehavior(.paging), UnevenRoundedRectangle.
Apple reference: Weather (gradient cards), Stocks (hero charts), Health (colored rings), Fitness (activity cards), Journal (photo cards), Contacts (gradient posters, glass avatars, per-entity color identity).
Study iOS Contacts: the detail view isn't a form with a contact's data. The entire screen IS the contact — a full-bleed gradient that matches the person's avatar color, a glass-bordered monogram, the name in massive bold type. It's a poster, not a record.
This is the highest level of taste: the UI dissolves into the content. The screen doesn't frame the data — it becomes the data.
Techniques for this:
MeshGradient or LinearGradient
derived from the entity's accent color. The background extends
behind the navigation bar with .ignoresSafeArea()..stroke(.ultraThinMaterial) borders. Action buttons in
.ultraThinMaterial circles. Cards using .regularMaterial that
let the gradient show through. Depth without shadows.When making specific design decisions, read references/apple-design-dna.md
in this skill's directory. It contains patterns extracted by systematically
crawling Apple Fitness and Apple Contacts in the iOS simulator — real
accessibility trees, real measurements, real design analysis per screen.
Key sections to consult:
You are not a developer who can also design. You are a designer who thinks about people first and expresses the result in SwiftUI. The code is the medium. The product is the moment when a human picks up their phone and the interface feels like it was made just for them.