Trying Claude Design on SwiftUI mockups

I had a question that the official page does not really answer: is the Claude Design plugin only useful for web, or does it also work for mobile? I work mostly on iOS, so for me this is the difference between “nice tool to read about” and “actual part of my workflow”. So I tried it on a few SwiftUI mockups and want to write down what I found. 🤔

This is not a benchmark, just my notes after a couple of afternoons playing with it.

What is the Claude Design plugin

The short version: it is an Anthropic-verified plugin that helps with design critique, UX writing, accessibility audits (WCAG 2.1 AA), research synthesis, and dev handoff. It installs into Claude Cowork and gives you a more design-focused experience than a blank chat.

The page does not mention iOS, Android, SwiftUI, React Native, or any specific platform. The tasks it covers are framework-agnostic on paper, so in theory it should work for mobile too. I wanted to check if that holds in practice.

My setup

I tried it on three SwiftUI mockups from a side project:

• A sign-in screen with email + Apple ID buttons
• A list screen with cards and a sticky filter bar
• A settings screen with sections, toggles and destructive actions

I screenshotted each one from the SwiftUI preview, dropped them into Claude Design, and started asking for critique, accessibility passes and copy iterations.

The good parts

Iterating visually is fast

Being able to iterate visually and then move straight into something buildable removes a lot of friction. I would sketch a rough idea, generate a couple of variations, pick a direction, and only then touch code. The preview step helps a lot — you catch UX issues early instead of after implementation. ✨

For a SwiftUI screen this is great, because the cost of “let me try one more layout” in code is not zero (Previews, modifiers, state). Doing the first 3-4 passes in the plugin and only implementing the winner saved me real time.

Accessibility audits are surprisingly useful

I expected the a11y pass to be generic, but on the settings screen it caught a couple of real things:

• A destructive action without enough contrast against the background
• Toggle labels that were too short to be clear out of context (good for VoiceOver users)
• A tap target on the filter bar that was under 44pt

WCAG is web-flavored but most of the rules map fine to iOS. For the parts that do not map (Dynamic Type, VoiceOver rotor, Reduce Motion), I still had to think on my own. 💡

UX writing in two languages

I write in English but ship apps for Spanish-speaking users too, and the plugin handled both fine. Asking for “shorter, friendlier, same meaning” gave me copy I would have spent 20 minutes massaging by hand.

Where it gets tricky

You still need to guide it

The only thing I noticed is that you still need to guide it pretty clearly, otherwise designs can drift or feel inconsistent across screens. If you ask for “make this nicer” three times in a row, you get three different visual directions. As a starting point it is honestly way faster than the old flow, but it is not a designer. You still need to hold the line on the system.

Token cost adds up fast

Opus consumes tokens very fast, so if you are doing basic stuff use Sonnet. Another approach I like a lot: use Claude Design for the overall macro design, then handoff to Claude Code for little adjustments. 🚀

This split works really well for SwiftUI because the little adjustments are usually code-level (padding, font weight, color tokens) and Claude Code in Xcode is fast and cheap for those. The plugin is better at “this whole screen feels off, propose three directions”.

Don’t make it carry the whole brain on every edit

This one I picked up from another user in the community and it matched my experience:

For some workflows I would avoid making Claude Design carry the whole product brain for every tiny edit. Use it for the macro pass, then hand off a much smaller artifact for iterations: screen name, design constraints, exact element to change, what must not move, and one screenshot/reference if needed.

Personas, epics, feature descriptions, and prior design rationale are useful once, but if they ride along on every “delete this button / move this block” turn, you pay for the whole project repeatedly.

A practical split: keep a durable design brief + component rules outside the chat, start fresh edit threads for small visual changes, and only paste the slice relevant to that screen. If the task is basic layout cleanup, use the cheaper/faster model lane when available and save Opus-style reasoning for ambiguous product/design decisions.

For me this was the unlock. Treat the durable stuff (personas, design system, brand rules) as a brief you reuse, and treat every small visual change as a fresh, narrow thread. Your bill goes down and the answers actually get sharper, because the model is not drowning in context that is not relevant to “move this button 8 points to the left”. 😄

My current flow for SwiftUI work

After a couple of weeks, this is roughly how I use it:

1. Macro pass in Claude Design — explore directions, get 2-3 variations, pick one.
2. Accessibility + copy pass — same screen, same thread, but framed as a critique.
3. Handoff to Claude Code in Xcode — implement the chosen direction in SwiftUI, with the component rules from my design brief.
4. Small visual tweaks — fresh threads, one screenshot, one ask. Sonnet, not Opus.

I keep the design system rules (spacing scale, color tokens, type ramp, component variants) in a doc that I paste into the brief once per project, not per turn.

So, mobile or web only?

To answer the question I started with: it works for mobile. Nothing about the plugin assumes web. The accessibility rules are web-flavored but mostly map. The visual critique and UX writing are platform-agnostic.

What it does not know natively:

• iOS Human Interface Guidelines specifics (the difference between a NavigationStack push and a sheet, when to use a Menu vs a ConfirmationDialog, etc.)
• SwiftUI primitives (it will not say “use LabeledContent here”)
• Dynamic Type scaling behavior

So you still need an iOS brain in the loop. But for the parts where design is design — hierarchy, contrast, copy, flow — it is helpful regardless of platform.

Final thoughts

The plugin is not going to replace a designer, and it is not going to replace Claude Code for the implementation side. But as the macro pass for a SwiftUI screen, plus an accessibility and copy check, it is good enough that I now reach for it before opening Figma for small things. 😅

If you ship mobile apps and you were waiting for the iOS version of this plugin: there is no iOS version, but you don’t really need one. Treat your screenshots as the input and you are 90% there.