May 17, 2026
I Replaced Figma Wireframes with SwiftUI Prototypes
A while back I wrote about how I approach micro animations. With a decent AI tool and enough prompting, you can get close to the final result without leaving your design environment. Since then I've taken the workflow further, and I'm starting to see how it changes a much bigger part of my process. Not animations. Wireframes.
The thesis is simple. For complex flows, prototyping in SwiftUI with Claude Code beats drawing gray-box wireframes in Figma. I'm not the only one saying it. Jenny Wen at Anthropic, Brian Lovin at Notion, and designers at Jane Street have all written some version of the same idea over the past year. This post is my take, with a real example, the time it took, and where the workflow still falls short.
The example is Plutus, an iOS expense tracker I built for myself in SwiftUI using Claude Code inside Cursor. I'll show you what came out, what the workflow looked like, and why I think AI is not going to save designers time the way the marketing suggests.
Why I'm done drawing wireframes for complex flows
I've spent endless hours making wireframes. Boxes, arrows, callouts, repeat. When a project is complex enough that the interaction is the design, wireframes become a tax. They take days to make and you still don't know how the thing feels.
That said, wireframes are not dead. For simple flows, for aligning a stakeholder on structure before anyone spends real time, for sketching architecture on a whiteboard, they're still the right tool. The piece I'm pulling out is the one in the middle: the moment after I have personas and user flows, when the next thing on my list is to draw fifty screens of gray boxes.
Up to now, I would have just done it. Open Figma, build a wireframe system, place rectangles where buttons go, write "Date" where a date should be. A few days later I'd have a clickable Figma prototype that still hides every interaction behind a static frame. The transitions are imagined. The bottom sheets are screens, not sheets. The bounce of a button is whatever your reviewer imagines in their head.
The alternative is to go straight to working code. The case here is Plutus, and the side-by-side below is the entire argument of this post.
The workflow that replaced wireframing
The prep doesn't change. I still start with what I always start with. Personas, user flows, what the user actually needs to do on each screen, what's annoying about the apps that already exist. For Plutus the persona is me, so this meant writing down what bothers me about every expense tracker I've tried. That part takes the same amount of time it always has.
The new part is what happens next. Instead of opening Figma, I open Cursor with Claude Code attached and start prompting my way into SwiftUI screens. I give it the persona, the flows, a basic structure I've sketched on paper, and I prompt screen by screen, component by component. A SheetHeader. A QuickActionBar. A MonthSelectorButton. A SpendingBreakdownBar. The folder structure builds itself.
It is not a one-shot prompt. That's important because everyone reading this expects "one prompt, full app" and that's the lie I want to correct. For Plutus I sent hundreds of prompts. Some were two words long ("fix spacing"). Some were three paragraphs and a reference image. Most fell somewhere in between.
What you get at the end of that loop is not a prototype in the Figma sense. It's a working iOS app you can build and run on your phone. That's the whole point of the next section.
What you feel on device that wireframes never gave you
This is the part nobody talks about enough. In Figma, an interaction is implied. You draw two frames and connect them with a transition that approximates what will happen on a real device. The reviewer imagines the rest. On a real device with a SwiftUI build, the interaction has weight. It either feels right or it doesn't, and you don't have to guess.
I'm not saying anything new here. The Apple Maps designers made the same point in their WWDC23 Design with SwiftUI session. They prototyped a Digital Crown zoom for watchOS and built it in SwiftUI, and as soon as they tried it on a real Apple Watch they realised the zoom was much too fast. That's not a thing they could have caught in any flat tool. They had to feel it.
For Plutus the same thing kept happening. Bottom sheets that looked correct in the preview felt heavy when I pulled them down on the phone. A haptic that hit a beat too late. A spring on a number ticker that was fine in isolation but distracting when the rest of the screen was moving. I caught all of these in seconds because the prototype was running, not because I was good at imagining motion in Figma. None of these would have made it into a wireframe review.
Plutus on device. Most of what's worth reviewing in this post is in the haptics and the transitions, not in the screens themselves.
There's a second-order effect here worth saying out loud. When the prototype is real, the people you show it to behave differently too. They tap, scroll, drag, and tell you what feels off. They don't tell you what they think the static design means. The conversation shifts from "do you understand what this is supposed to do" to "does this feel right when you do it." That's a much better conversation.
Where the AI-generated design still falls short
This is the section I have to write honestly. The design that comes out of this workflow is, at this stage, not where I want it. I tried everything. DESIGN.md files. Detailed prompts. Reference images. Context engineering. Better prompting. The output stays flat. Hierarchy is mostly there. Spacing is mostly there. But the things that make a UI feel considered, the small typography choices, the right amount of weight on a divider, the icon that fits the family instead of being plucked from SF Symbols at random, those are not happening.
Look back at the right side of the comparison image above. The SwiftUI prototype is functional. It's also generic in ways I'd never ship. The typography is fine but doesn't have a voice. The category icons are default SF Symbols colour-tinted, not a curated set. The spacing has small inconsistencies I'd catch in a Figma review in three minutes. None of it is broken. None of it is good either.
The workaround is partial. Knowing the basics of SwiftUI means I can patch a small thing myself without prompting. A padding value, a font weight, a border radius. But for the bigger move from "functional" to "considered," I'd still go to Figma. Or, more accurately, I'd treat this prototype the way I treat any wireframe. I don't look at the visual design. I look at flow, structure, and interaction. The visual layer comes after, and it comes in a different tool.
Anton Sten puts it well in his piece on vibe coding for designers: AI is a builder, not an architect. You're still the architect. That holds for the visual layer too. The AI builds. You decide what's worth keeping.
This is for prototyping, not for shipping
The workflow above is for product design and better wireframing. It is not for shipping production code. I want to be clear about that because the broader vibe coding conversation tends to blur the line. The code Claude generates inside Cursor is good enough to feel an interaction. It is not good enough to be a production codebase. Real engineers maintain real codebases. Recent reports on AI-generated code consistently find higher defect rates and more security issues than human-written code. I have no interest in pretending otherwise.
What I'm doing is using the same tools they're using, for a different output. The output is a clickable, runnable, on-device wireframe. Not a shipped app. The engineers I work with would rebuild every file. That's fine. The point of a wireframe was never to be the final thing.
The time math: eight hours and hundreds of prompts
The honest accounting. The eight hours below does not include the time I spent writing down what bothers me in existing expense trackers, because that's persona work I'd do for any project. It also doesn't include the basic structure I sketched on paper, because that's also work I'd do anyway.
What it does include is the time it took to get from "I have a structure" to "I have two main screens, one settings screen, and a handful of bottom sheets each with their own internal flows, running on my phone." That was eight hours of focused work.
Real-time elapsed was much longer because I worked on this in my free time, in small windows. And because the workflow is hundreds of prompts and not one, I hit the Claude limit on the Max plan several times. There is no extra usage budget for a personal project, so I'd just stop and come back later. Worth mentioning if you're planning to try this on a real project under deadline.
Eight hours is not fast. I want to say that plainly, because the next section is the lesson.
AI didn't save me time, it made the result better.
I've been doing this long enough now to know that AI is not going to save me time the way the marketing keeps saying it will. I'm not working fewer hours. I'm working the same hours and the artifact at the end is better. That's the trade I've made peace with.
The numbers back this up. Figma's 2025 AI Report found that 67% of developers say AI improves the quality of their work, but only 54% of designers say the same. A thirteen-point gap between two groups using the same tools. I read it as designers being more honest about output quality. We see more of the surface. We notice the things that are almost right but not quite, because that's what we're trained to do.
Same hours, better artifact, better thinking. That's the trade, not faster but better.
If you came to this post hoping for a workflow that lets you do more in less time, this isn't it. If you came for a workflow that lets you prototype something complex without three days of gray boxes, while also catching interaction problems you'd otherwise miss, this might be it.
FAQ
Can designers use Claude Code?
Yes. You don't need to ship production code to benefit from it. Basic familiarity with the language helps you patch small things without prompting, but you don't need it to get a working prototype. The prompting is what does the work.
Is SwiftUI good for prototyping?
For iOS, very. You get real animations, real haptics, real gestures on the actual device, with very little overhead between the code and the result. Apple's WWDC23 Design with SwiftUI session makes a more thorough case than I can.
Does AI replace wireframes?
For complex flows, often yes. For early stakeholder alignment or quick structure-sketching, wireframes are still faster. The answer depends on what the wireframe was for in the first place.
If you want the predecessor, I wrote about how I approach micro animations and it't the next post after this, or find it here. This post is the next step in the same thread.