Minds/

Is Figma still the only source of truth that we need?

A mobile feature designed in Xcode and Android Studio instead of two hundred Figma screens, and what that did to the process.

Jul 2026/Originally posted on LinkedIn/3 min read/

Half a year ago, when a designer picked up a new task for a mobile app, it took a lot of time. If it's two separate native apps, iOS and Android, you had to design against both platforms' guidelines. For a bigger flow, that meant a pile of screens in Figma and time spent explaining interactions and behaviors to developers.

Recently, we've been actively using code-based prototypes. In fact, we started experimenting with this approach before Claude Code or Lovable became popular, back when V0 was one of the few available tools.

This time, I decided to take the same approach for a mobile app feature.

And you know what? It was just wonderful. The whole thing, process and design, was built in Xcode for iOS and Android Studio for Android.

A printed design receipt listing Claude Code, Xcode, Android Studio and Figma with an asterisk: not sure. Total: great result and happy me.

The biggest shift is that you stop thinking in screens and start focusing on the problem you're actually solving. You don't have to hold both platforms' guidelines in your head: they come out of the box, and Claude Code understands that perfectly. All the native platform components are right there too: segmented controls, sheets and drawers, animations, and so on.

Testing a code-based prototype natively doesn't even compare to having 200+ screens in Figma, 100 of which exist just to show how a native drawer slides up 🫠

Once it was ready, the iOS prototype went to TestFlight, and for Android I built an APK, so I could run real testing on both platforms. Which I did.

Another major advantage is working with data that is much closer to reality instead of static mock content. During testing, it quickly became obvious that we needed quick filters to make navigation easier.

If I compare it all overall, right now it feels like two separate approaches.

Because the most tedious part was then having to move everything back into Figma, assembling it piece by piece like a construction set, and it's a strange feeling to be showing, on some screen, how a native dropdown appears somewhere. It feels like reverse engineering, and honestly it no longer feels like a necessary step.

Claude helps there too: when a component didn't exist in the design system, I'd ask it to create one in Figma with a description of what it's for, which removes a lot of the routine. It can actually port all the prototype screens as well; my point is more that this step is starting to feel redundant.

And the upsides are many, from time-to-completion and the quality of testing, to the way you think while working on the task itself.

I'm not arguing against Figma. I'm questioning whether a collection of screens should still be the only source of truth. My point is about the gap between designing in Figma and designing code-based: they're two genuinely different processes. I'm talking about the approach, and the one that, for now, simply works better for me. And about the bigger idea behind it: screens that live only in Figma can hardly remain the single source of truth anymore.