Judo & the Future of SwiftUI Design
A chat with John Coombs and Sean Rucker about the future of design tools, and their vision for reshaping designer/developer collaboration with SwiftUI apps
Updated Aug. 11, 2023 with reference to Judo 3.0’s new features
In my recent discussion with No Handoff evangelist Shamsi Brinn, one of her keys to eliminate handoff friction between designers and developers is to use prototypes as the sources of truth. From nohandoff.org:
Prototypes are the true shared language of the team. All stakeholders can understand them intuitively, and even a very rough and unpolished prototype can leapfrog many stages of assumption and misunderstanding. Prototypes are the vehicle for interdisciplinary teams to regularly iterate on a shared deliverable.
The phrase “shared language” resonates with me. I’ve always felt that shared language — whether prototype, process, or tool — is the key to reshaping the future of design.
In 2021, I wrote about the value of a “shared language” design system…
…that doesn’t need tokens or code conversion, because the design system is already coded in the same language developers use.
For those that design in SwiftUI for the Mac, iPad, iPhone, Apple Watch, Apple TV — and Vision Pro in the near future—a new product challenges the status quo and makes people rethink how design tools should work with code.
That tool is Judo.
Why Judo Is Different
For the past few months, a few of us at Lextech have been evaluating Judo as an alternative to Figma to design SwiftUI apps.
While Figma is a great vector design tool, it is not built for real prototyping on iOS or iPadOS.
For years, I’ve had to struggle with issues such as a Figma prototype being unable to resize to a different iPhone screen, or the inability to test Dynamic Type or the effects of localization.
This is where Judo sweep kicks other design tools. Judo automatically supports functional prototype features that prove impossible or incredibly difficult in Figma and Sketch:
- Automatic conversion of design to SwiftUI code with Judo’s SDK
- Connecting your prototype to real-time data APIs
- Prototype orientation changes (e.g. landscape to portrait)
- One-click size classes to see design at different screen sizes
- Built-in support for accessibility features such as Dynamic Type
- Light/dark mode support that exactly matches Apple’s implementation
- Support for localization (also matching Apple’s implementation)
- Support for inputs (e.g. sliders, steppers and form fields)
All these features are built into Judo without the need for additional plugins or code converters, because the biggest strength of Judo is that it’s a visual designer powered by SwiftUI under the hood.
Concepts such as reusable components, layers and an infinite drawing canvas help create an environment in Judo that interface designers will be familiar with. For those new to SwiftUI, Judo helps designers learn the basics behind how SwiftUI works.
In the latest version of the app, Judo 3 adds support for SwiftUI controls such as steppers, sliders, toggles, text fields, secure text fields and pickers.
Judo’s future roadmap includes buttons that can trigger state changes in the Judo file. This will make Judo prototypes even more interactive and functional even beyond the addition of the SwiftUI controls mentioned above.
The Game-Changing Difference
For all the talk around design tokens and variables, Judo goes way beyond both those concepts.
Imagine embedding a version-controlled design file in Xcode, automatically synced to update the developer’s SwiftUI code in real time.
With traditional design tools, this is impossible. (In fact, tools such as Figma are going in the exact opposite direction: Adobe is doubling down on a dev-mode plugin ecosystem that adds yet even more integration complexity to the product, adding layers of management that widen the distance between design and code.)
In sharp contrast, Judo makes the design-to-code flow amazingly simple:
- A developer adds the Judo SDK to their Xcode project
- A designer puts the Judo file under version control
- Checked-in changes to the Judo file update in Xcode.
That’s it!
The only way to make this workflow simpler is for designers to actually learn SwiftUI for prototyping. Until then, Judo is in a great position to bridge that gap between visual design and SwiftUI code.
Even if a developer didn’t want to use the Judo SDK, Judo designs are documented in SwiftUI: no code translator or plugin needed. Because Judo generates pure translation-free SwiftUI code, developers know exactly how to implement it.
In the words of one Lextech developer who helped me evaluate Judo:
“Even if we only use 10% of the code generated in a Judo file, it is an incredible time saver. It’ll show me the exact specs I need to implement, so there won’t be time wasted with the usual back and forth with the designer.”
If Judo succeeds in the market, it could revolutionize how designers and developers collaborate to build SwiftUI apps. If nothing else, it has made me question the status quo workflow between designers and developers.
Because in Judo, the design is the code, the code is the design. And the best design workflow is when designers and developers speak the exact same language.
The Genesis of Judo
Judo’s origin story begins with a chance encounter in Toronto between John Coombs (CEO of Judo) and Sean Rucker (Chief Product Officer) nearly a decade ago.
Back then, both John and Sean saw the value of mobile phones as a way to build customer loyalty. As a result, they began to develop consumer marketing app experiences that leveraged technologies such as geofencing, Bluetooth beacons and contextual awareness. Ultimately, their first SaaS offering was a CMS that helped clients manage these customer interactions.
To keep this business going, John and Sean quickly found a need to create an internal design tool to help them rapidly build and deploy new native app experiences for clients, most notably for professional sports teams who wanted to keep their fans engaged. And as they were “in the trenches” with their clients, they quickly saw the value of a high-quality design tool to make development easier.
And thus, the seed for Judo was planted.
For the past two years, John and his company Rover Labs have been bootstrapping Judo’s development, which was originally intended to support their existing customers’ needs for a no-code design tool. Not surprisingly, the problems Judo was solving for are very universal, and so last year, the team officially launched Judo for “prosumer” use.
I had the opportunity to chat with John and Sean about why they believe Judo is the best thing to happen to mobile app designers in years, and will force everyone to rethink the designer-developer workflow.
Nelson: John and Sean, thanks so much for chatting with me. Design tools today: Where are they failing to meet the needs of product teams?
Sean: Based on our company’s research and experience with numerous product teams, what’s slowing them down is what we’ve been calling designer-developer handoff. There’s this frustrating back and forth cycle that was common to a lot of the people we talked to.
They have a designer who comes up with this vision, and creates it in Figma or Sketch, right? And what they’re creating is just a picture for what they want the developer to build, and then the developer has to go and translate by hand, with his eyes looking at the document, and turning it into code.
Some developers are better than others at diving into Figma and actually measuring things properly … and some developers just completely eyeball it.
I’m familiar with this process. It is manual and prone to error.
Sean: So one part of the problem is that back and forth where designer hands off an image, developer builds the user interface, developer hands it back for testing and the designer identifies problems.
I talked to a lot of designers and asked them, “How do you check the builds they deliver for errors?” And they said, most of the time, “I take a screenshot on my phone, I drag it into Figma, I put it over top of my image. I drag the opacity down, and I try to see what’s out of line, what’s the wrong font size? How is the spacing?”
That process is tedious and it’s just a lot of back and forth. We talk to developers about this process. They hate it too. They say translating the user interface from picture to layout code is not rewarding programming work. It’s just going through the motions.
Sadly, I think you’re describing a fairly common scenario for designers.
Sean: And then, the other kind of problem we saw with this designer-developer handoff is designers’ lack of understanding of what’s possible. So they would be designing things, whether it’s a certain style of button or a way of doing navigation, and the mobile developers would be like, you can’t do that. That’s not the way that navigation works on iOS, we have native components for buttons, but they don’t support the design you’re proposing.
iOS has a built-in tab bar, and if we use that, it’s going to take me 10 minutes to implement. If I need to recreate this custom one you’ve designed, it’s gonna take 10 weeks.
A lot of what you describe I’m familiar with. I’ve seen both sides of the challenge working as both a designer and developer myself.
Sean: What makes things harder is that the only place where designers can really understand what’s possible is in the developer documentation: Apple’s human interface guidelines. It’s a good starting point, but they’re quite vague. They don’t go into the detail of what a designer can or can’t do if they use the button component. Can I change the font size? Can I change the corner radius?
So there’s this lack of understanding and no real way to educate themselves on the designer side. And then on the developer side, they’re frustrated. They’re getting designs that are not possible to create.
Why do you think Judo is better equipped to address this gap?
Sean: I’ve been witnessing problems like this my whole career, and it’s shocking that it hasn’t gotten better.
So we at Judo got really excited about this fundamental underlying problem that product teams were experiencing.
Our mission with Judo is to help designers learn the capabilities of SwiftUI and design in harmony with best practices, but do this within an interface that is familiar to them as Figma and Sketch.
So a designer doesn’t need to learn XCode or use Swift Playground to mock things up?
Sean: The power of Judo is that when a designer makes a picture of an interface, and a developer writes code for it, they can live in the same tool that is familiar to both of them. So as the designer is making decisions about color and font choices and spacing and padding and, and layout, it’s done! There isn’t an extra step. No additional translation needed.
Imagine if in Figma your design could just be dragged into Xcode and if the interface is done, that’s kind of the vision for what we’re trying to do with Judo.
I see Judo as a leveraging tool that helps make every designer more efficient by surfacing the SwiftUI APIs that they’re designing for into the tool in a familiar, visual-first way that the designer understands.
Another big part of what we’re doing with Judo is that when you’re working in Figma or Sketch, you have art boards. You pick a medium-size phone and you design all your screens, perhaps in your native language and in light mode.
But now, you have to think about dark mode, different screen sizes, localization, and so on. This results in tons of permutations and an explosion of art boards that require design and maintenance.
I agree. This is a very time-consuming part of a designer’s workflow. How does Judo simplify this work?
Sean: With Judo, the art boards themselves are dynamic. So you can toggle light mode and dark mode. You can change the screen sizes. You can flip to horizontal, see it on iPad. You can add different languages, and you can adjust — this button looks great, but when it’s translated to German, it doesn’t quite fit any more.
So it gives the power to the designers. It gives time back to developers, because it empowers designers to work out all those kinks and edge cases themselves. And when the design is done, the developer just drags the Judo file into Xcode and the user interface is already built, so the developer can focus on the hard things.
So tools like Figma and Sketch rely on plug-ins to help translate design into code. What are your thoughts around that?
Sean: First of all, they do a pretty much garbage job, but it’s not the plug-in’s fault.
A Figma file just doesn’t contain enough information about what the designer’s desires and intentions were and how those accurately translate to code.
In addition, if you copy and paste that code, it may work once, but then as the designer’s making changes to their Figma files, how do you keep them in sync? So do you just copy and paste all the code over again, and then see what changed?
Most developers I know would see such a workflow as highly unmaintainable.
Sean: Exactly. So we wanted to take a different approach with Judo, which is, you don’t have to copy and paste code. You just drag the actual Judo file into the Xcode project and the Judo SDK will render it.
For those familiar with Xcode storyboards, it’s just like that: Judo is like the storyboard. It is a file that you build the user interface in, and it lives in your Xcode project. The developers wire up the button clicks. So when you click that “add to cart” button, the developer has some sort of handler to say, “Okay, now I’m gonna actually perform the code required to add that product to cart.
Is the storyboard approach limiting for designer exploration?
Sean: Just the opposite: In Judo, the designer has full control over the layout, presentation, colors, typography — everything related to the user interface.
And that’s just the start. Judo goes way beyond what other design tools can do, especially when it comes to accessibility.
For example, a lot of people increase the size of text on their phones, which is a feature called Dynamic Type on Apple devices. In Judo, you can play with Dynamic Type in your design and see it adapts to different settings users are going to have.
Another accessibility feature on iOS is called Increase Contrast. In Judo, you as a designer can define how you want a screen to look, but if the user has Increase Contrast on, you can choose, test and preview how the app looks.
You can also test different languages. So we have a tool you can use to put all your translation files in here. So if you wanted to preview your design in Arabic, which is a right-to-left language, you can easily do that.
Where do you see the future of design tools going? Similarly, what do you wish for the future of Judo?
John: So a big part of where I think the market for design tools is going is closer to functional software: That to design, inherently becomes, to build.
Today’s designers are more technically savvy than ever before, allowing them to take work beyond the design phase of product development, and closer to functional software. The growth of new no-code and low-code tools, as well as the emergence of AI to support code generation, is further helping to accelerate this trend.
In parallel, UI development frameworks such as SwiftUI are becoming more accessible to designers looking to further their designs into production-ready software. These realities are blurring the traditional distinctions between the role of designers and developers, and I’m excited to see where this future takes us.
For my part, I am super excited for the future of design thanks to tools such as Judo that shorten the gap between interface design and developer code.
If you do get a chance to try out Judo, please let me know what you think!
Nelson Taruc is a design lead at Lextech, where they help some of the world’s most admired companies end enterprise workflow chaos. With Lextech, employees become more effective, efficient and engaged in the enterprise.
