[00:00:00] What is Judo
---

[00:00:00] Leo Dion (host): Welcome to another episode of Empower Apps. I'm your host, Leo Dient. Today, I'm joined by Sean Rucker. Sean, thank you so much for coming on.

[00:00:12] Sean Rucker (guest): Thank you for having me

[00:00:14] Leo Dion (host): Sean works with Judo, which is a app that's currently in beta, right?

[00:00:22] Sean Rucker (guest): We're in a soft launch phase. We'll call it. We'll call it

[00:00:25] Leo Dion (host): launch.

[00:00:26] Leo Dion (host): So we're going to talk a lot about SwiftUI and Judo today. Before we begin, I'll let you, Sean, go ahead and introduce yourself.

[00:00:33] Sean Rucker (guest): Hi, my name is Sean Rucker. I am the I'm the chief product officer and co founder of Judo. I've got a background in computer science and experience working as a developer. A lot of experience with SwiftUI. I've also played the role of product designer and have designed and built a lot of apps.

[00:00:54] Sean Rucker (guest): And sometimes I call myself a product manager as well. So I wear a lot of different hats on different teams. And, yeah.

[00:01:01] Leo Dion (host): That's interesting. So you've done some design work as well. Any apps that we would know about.

[00:01:07] Sean Rucker (guest): A lot of web apps when it comes to mobile apps, which is what Judo specializes in. A previous company that I co founded called Rover and Judo, the Judo iOS app as well.

[00:01:19] Leo Dion (host): Yeah. Okay, cool. So you must've found a lot of pain points when it comes to design and developers. Tell us the origin story of Judo and how it came from that.

[00:01:30] Sean Rucker (guest): Yeah Judo is I think it'd be helpful to just tell you what Judo is itself. Judo is a tool for designing and building iOS apps. And it's very similar to Sketch or Figma, any general purpose design tool. You'll see a lot of similar concepts to those tools, similar keyboard shortcuts, etc.

[00:01:50] Sean Rucker (guest): But it's purpose built for iOS apps. And what that means is Judo surfaces the underlying framework that's used to build iOS apps into the tool. And in iOS apps, that is SwiftUI. So Judo brings like the power of native SwiftUI views and modifiers. Puts it in the hands of the designers, but in a more friendly visual canvas instead of code.

[00:02:13] Designer/Developer Handoff Problem
---

[00:02:13] Sean Rucker (guest): The backstory was born from a problem that I've felt many times in my career. Being both a developer and a designer and being on both sides of the fence. And that's a problem that I like to call the designer developer handoff problem.

[00:02:30] Sean Rucker (guest): So I think any developers listening to this podcast may resonate with this. On the developer side of things, I'm often handed designs from Figma or Sketch that I just know as a developer are not really a good fit for the platform. Sometimes the designer has tried, proposing things that are impossible or just...

[00:02:51] Sean Rucker (guest): a lot of extra work because they're not familiar with the tools that developers have, in this case SwiftUI, and what the limitations of those platforms are, as well as what are some of the great things you get for free from these platforms. One example I like to talk about is a tab bar, so often I see designers designing mobile apps and they've created their own custom tab bar at the bottom, and they, maybe it's a full like capsule style and it's floating or something to that effect.

[00:03:25] Sean Rucker (guest): And when a developer or SwiftUI developer is going to see that design, they're thinking. SwiftUI comes with a tab bar, and it adapts for iPad and iOS, and it works with all the accessibility options, and accounts for light mode and dark mode, and makes sure it gets out of the way of the safe area, so it's not going to be conflicting with the the home buttons, etc.

[00:03:48] Sean Rucker (guest): And I can just plop that in, and it'll take me about two minutes, or I can hand code this very custom tab bar that the designer has created. And that's going to take us two to three weeks to build. So that's kind of part of the frustration that developers can feel. And, a lot of it is just designers not understanding the underlying framework and what a good fit and a bad fit is for the platform.

[00:04:13] Leo Dion (host): Yeah, I think a lot of it is, like you said, ignorance just of Apple specific platforms and just taking what they build on the web and moving it over to And yeah, I think it's super important that, okay, in some cases you might get clients that are stubborn and it needs to look like this.

[00:04:31] Leo Dion (host): It absolutely 100 percent needs. It's okay, that's fine, but it's going to take like X weeks and it's going to be X, X more work or Y more work to maintain this thing because you're asking me to customize every little nook and cranny.

[00:04:46] SwiftUI and Design
---

[00:04:46] Sean Rucker (guest): Yeah, I think you bring up a good point there. One is designers coming from web. Where when I look at the web, it's very much a blank slate, it's HTML, CSS, it's open, it's an open standard, right? So you can design and do whatever you want on the web. But when it comes to iOS and SwiftUI specifically, you're almost inheriting a design system, right?

[00:05:10] Sean Rucker (guest): SwiftUI, you can think of it as a design system. It has a bunch of built in components, and it has built in ways of doing things, and so it's really important for the designer to understand where they're starting from, and it's not like the web where it is just a completely blank canvas, right?

[00:05:28] Leo Dion (host): Yeah, it's closed both for a business reason, but it's also because Apple is highly opinionated as far as design standards are concerned. And it's you can customize this, but not this. And this is why. And, if you've ever looked at the human interface guidelines, you've seen how, like they have specific things that they want, whereas with CSS or JavaScript or TypeScript, you can pretty much do whatever the heck you want with it. And there is no standard.

[00:05:54] Sean Rucker (guest): Definitely. That's another good point that the Human Interface Guidelines or the HIG as some of us call It's a great resource for designers, but it really doesn't go far enough It talks a bit sort of the high level concepts of you know when to use a pull down button and when to use a tab bar Etc, but there's details in all of these components that really only live in the developer documentation So if you think about a button in SwiftUI there's button styles that come with it, and there's a handful of them.

[00:06:27] Sean Rucker (guest): One of them gives it a colored background, one of them gives it a border. But if you want to use that component, you can't just completely freeform choose what you want to do there. And some components are a little bit more flexible than others, and some are more rigid, but the details of what you can and can't change Really only live in the developer documentation and that's just not friendly for a designer.

[00:06:51] Leo Dion (host): Yeah. It goes to my next question was just like how much customization we lose with UIKit. I assume that was a pretty big challenge going from UIKit to SwiftUI. When it came to Judo is, cause you built Judo with only SwiftUI in mind, right?

[00:07:09] Sean Rucker (guest): Yes, definitely. SwiftUI is a great tool for getting the bulk of your design in your app built very quickly. But you customization options. And on that note, just to go back to the designer developer handoff problem. It goes two ways, right? The designer creates these designs and then is at the mercy of the developer and has to hand their designs over and the rely on that developer to do what I call translation work, which is to look at a design which is a static picture and then using their eyes translate it into code.

[00:07:50] Sean Rucker (guest): That's a very error prone process and sometimes the designers designs aren't quite exact what the developer needs to read. And sometimes the developer fudges things or best guesses items. And then there's this quality control process where the build is handed back to the designer who then finds all these mistakes, or that's not what I had intended, or this should be this point size, or this padding.

[00:08:16] Sean Rucker (guest): I talked to a lot of developers about how they do that, and it's quite archaic, really. It's, they take a screenshot of the app and then overlay it, reduce the transparency in their design tool, and try to match their design up and see where all these mistakes are. And that's where Judo, what Judo was born from.

[00:08:34] Sean Rucker (guest): Why do we have to do this work twice? The designer's already meticulously positioned things, decided what the padding should be, what's the font size, what's the color gonna be and the developer's just going ahead and doing that work again. The designer's really only producing this intermediary, deliverable and the back and forth is just frustrating on both sides, right?

[00:08:56] Sean Rucker (guest): Like developers. Don't want to spend their time doing this mindless translation work. They want to be working on the hard stuff and the designers want to have control over the user interface. So the vision for Judo is to bring designers into the build process. Let them have ownership of the construction of the user interface and let developers focus on the quote unquote hard stuff.

[00:09:21] Sean Rucker (guest): One example I like to use is like a checkout screen. So the designer should be able to position the text fields and design the button and decide the padding and the colors, et cetera. And then the developer should be focused on what happens when the user hits that checkout button. And so Judo is a, it is a native Mac OS app.

[00:09:44] Sean Rucker (guest): It is a file based app. And so that allows the document, the design document to live right in your Xcode project, live in your GitHub repository. And allow the designer to be part of that build process instead of just handing things back and forth.

[00:10:00] Leo Dion (host): Dude, have you gotten feedback from designers as far as Oh, I love this app, but it ties my hands and I can't say exactly what I want. I can't have it look exactly like I want it to look. You know what I mean?

[00:10:17] Sean Rucker (guest): Yes we've heard it, we've heard that used as a negative but more commonly used as a positive, actually. Because it's putting up these guardrails for them and keeping them designing in the constraints of what's possible. A lot of designers are looking for that. They're frustrated by developers telling them, Oh, you can't do that or that's not a good choice here.

[00:10:38] Sean Rucker (guest): And Judo, part of our vision is to bring those human interface guidelines to the surface of the tool itself. Bring the components into the tool itself, show the developer what's possible, and prevent them from wasting their time designing things that just don't work.

[00:10:53] Leo Dion (host): Let's talk about some of the stuff you learned. Obviously this was built with SwiftUI in mind. Do you think there was ever a possibility of having something like this available for UIKit before the advent of SwiftUI?

[00:11:07] Sean Rucker (guest): I think it could have been possible, but it would have been much, much more difficult. I think the... The way that a declarative UI framework works, just like HTML and CSS lends itself so much nicer to a tool like this. I think Webflow has done an amazing job of bringing HTML and CSS into the hands of the designer and allowing them to be part of the construction of the user interface.

[00:11:35] Sean Rucker (guest): And I see a lot of parallels between HTML, CSS ,and SwiftUI. For technical reasons, but also it's just much more intuitive to understand.

[00:11:45] SwiftUI vs Web Design
---

[00:11:45] Leo Dion (host): You have some experience with web design and stuff, so what are some things that you wish SwiftUI would have that the web folks have as far as design and development is concerned when it comes to like SwiftUI?

[00:11:57] Sean Rucker (guest): I think just maturity. And I think we're on a great path already every year. I think it gets better and better. Three years ago, SwiftUI was not super viable to, to build an entire app with today, I think that's very much possible and it's just getting better better and better.

[00:12:15] Leo Dion (host): what do you think are the key parts of that we're missing?

[00:12:19] Sean Rucker (guest): I've dropped down to in my own development when I'm working on Judo, I find myself dropping down to UIKit and app kit a lot. And that's just because of the customization options.

[00:12:29] Leo Dion (host): Got you. Okay.

[00:12:30] Sean Rucker (guest): yeah, SwiftUI is so much faster for building a user interface. It's so much more resilient and stable.

[00:12:40] Sean Rucker (guest): But you can really customize a lot more in UIKit and AppKit. And as I see SwiftUI maturing every year, we're starting to be able to have our cake and eat it, too. We're going to get all the benefits of SwiftUI, and they keep adding more modifiers and more customization options to those controls. So yeah, I'm excited.

[00:13:02] Leo Dion (host): So what are some other major things you learned about SwiftUI and what goes on underneath with the development of Judo?

[00:13:11] Sean Rucker (guest): I think one of the biggest things I learned with SwiftUI is the performance. Characteristics. It can be incredibly performant in, the 99 percent of cases, but when you try to do something really ambitious with it, it gets a bit finicky. For any SwiftUI developers out there who know what the observable object protocol is one of the challenges we ran into is that any view that is observing that object is going to update anytime any of those properties change.

[00:13:45] Sean Rucker (guest): And so if you have a very, what I'll call, hot object where properties are changing rapidly, it could cause your whole user interface to be updating. And so if you think about Judo, which has a canvas and an inspector panel and a layers panel, we had an object that had a property on it which was the current scroll position or mouse position on the canvas.

[00:14:08] Sean Rucker (guest): You can imagine how often that's going to be updated. And so any objects that needed to access any views that need to access any of the properties in that object were just going to be constantly re rendering and having that view body evaluated. And that was a major performance bottleneck. And so what we found with SwiftUI is you end up having to structure your model objects around your user interface.

[00:14:35] Sean Rucker (guest): Which... Seems backwards but when you're really performance constrained, that's just what you have to do.

[00:14:43] Leo Dion (host): Yeah, we had that whole episode with Aviel where he looked at print changes and how much he could tell models were being updated and views were being updated. And yeah, it's crazy. I didn't even, is this still an issue when it comes to a Mac app where you may have. A ton more memory on that computer.

[00:15:03] Leo Dion (host): Is it still an issue there or is it like not so much compared with the way iOS works?

[00:15:08] Sean Rucker (guest): I think it's very much still an issue with Mac apps, and especially Mac apps, because when you think about an iOS app, you're looking at a very small portion of the screen at a time, and when you navigate to the next screen, The old one is gone. It isn't re rendering anymore. When you think about a Mac app, you have this huge amount of real estate and you can have lots of different views and, the inspector panel, layers panel, canvas windows, accessory windows, all these are the same size or bigger than an iPhone screen itself.

[00:15:45] Sean Rucker (guest): There's just a lot more going on in a Mac app and performance is especially important there.

[00:15:51] Leo Dion (host): I now I'm thinking what would it would be like on a vision pro too, especially considering how big that can be. So yeah, that makes total sense. One thing you actually have on here is. What came out at a WWDC and how that might fix performance issues. You think the observable macro is a big improvement in that case?

[00:16:11] Sean Rucker (guest): I think it's a massive improvement because, going back to this problem of having one object with lots of properties on it. Anytime any single property changes, every view observing that object is going to re render. With the new observable macro, SwiftUI got smarter. And if it's observing an object, and it's only observing, only needs one specific property on that object, That view is not going to re render if a property, it doesn't care about changes.

[00:16:42] Sean Rucker (guest): So going back to our canvas example, if we have a canvas model object with the current mouse position as a property, any views that don't care about the mouse position, they can still observe that canvas model, but they're not going to update as you're dragging your mouse around. It actually solves that problem where I was...

[00:17:03] Sean Rucker (guest): describing having to design your model around the user interface. We can go back to, good practice and design our model structure how it makes sense and then the UI will accommodate that instead of the other way around.

[00:17:17] Leo Dion (host): wHat were some of the features that you've seen people request that you were surprised about?

[00:17:24] Sean Rucker (guest): The biggest surprise to us and this was a, has been a common request, is integration with Firebase. For developers out there, Firebase is a... it's an SDK or really an entire platform from Google for bringing a lot of the cloud based features that you need to an iPhone app. You've got a content management system, analytics, authentication.

[00:17:49] Sean Rucker (guest): aNd so we've had a lot of customers asking for integration with that because they want to bring authentication into their judo design. Or bring content management system in there. And this surprised us because we really built Judo for teams for designers and developers to collaborate and work on the user interface of their app together.

[00:18:12] Sean Rucker (guest): We never really had the idea of building, of making it a truly no code build an app without any engineering effort type product, but we are getting a lot of users are finding us and using judo for that purpose. I think we talked to a lot of users. I'm a firm believer that's pretty much the most important thing you can do to build a successful startup.

[00:18:34] Sean Rucker (guest): And we hear this common theme, which is I've got this great idea for an app, but I've never been able to get it off the ground. There's this conception and or perception that is probably accurate that learning SwiftUI, learning Apple development, downloading Xcode for the first time. There's a big lift there and it's overwhelming for a lot of people and these are not non technical people.

[00:18:59] Sean Rucker (guest): A lot of these people are developers, but they're not iPhone developers or they're designers, but they're extremely tech savvy. It's just there's this big barrier to entry that they feel and Judo to them has been this. Entryway into getting an app up and running. And so they use Judo to design and build that user interface, and then they want to take it to that next step.

[00:19:21] Sean Rucker (guest): And they don't necessarily have access to an engineer or an iPhone developer. So that was something that was very surprising to us. It's something that we're thinking a lot about. I think it's pretty cool when you build a product, you have your user in mind, but sometimes the people who use the product or the way they use their product, isn't the way that you that you thought,

[00:19:40] Leo Dion (host): How do you avoid scope creep where you're essentially rebuilding X code? Inside Judo,

[00:19:47] Sean Rucker (guest): yeah, so far we have a really good sort of dividing line, which is if it's constructing of the user interface that's in scope. If it's. Wiring up button clicks or behavior, custom behavior that happens. That's out of scope today for what we're doing.

[00:20:05] Leo Dion (host): What have you really liked about Xcode 15 that you feel have been features that you think you're like, yeah that's great and something we could do in Judo as well, perhaps.

[00:20:18] Sean Rucker (guest): To be honest, I haven't been like wowed with Xcode 15 as in there's these must have features for me. I think the stuff I'm most excited about is really the additions to the Swift language and to the SwiftUI framework. Some of which we can't really take advantage of yet because we're not ready to bump our minimum required version of Mac OS quite

[00:20:40] Leo Dion (host): What's your minimum version right now?

[00:20:42] Sean Rucker (guest): Right now it's 12.

[00:20:43] Leo Dion (host): Oh, okay.

[00:20:44] Sean Rucker (guest): So we're up there and we actually, we tried to keep it at 11 but we just couldn't. SwiftUI just did not contain enough of what we needed to be able to pull off the experience that we wanted. And so we decided to make them minimum version 12, but we just did that recently. And so we're not quite yet ready to pump that again.

[00:21:08] Judo SDK
---

[00:21:08] Leo Dion (host): Yeah. How will that be going forward where it's like somebody wants to do SwiftUI animations? That's a designing thing, but then there you're building for only Monterey. Is there ways you're going to be able to get around that? Yeah.

[00:21:23] Sean Rucker (guest): Yes. So we do a lot of we, we do bring features that are so look, if we talk about from the SDK perspective, so that's another element of Judo. We have an SDK that developers can put in their app and what the SDK does, it just unpacks that judo file and renders it as native swift ey.

[00:21:43] Sean Rucker (guest): So our s D K gives us a little bit of a middle ground where we can write our own BACKPORTING code, and so we can take advantage of features in, in later versions of swift ey for the iPhone and bring them into the design tool. And then the s d K will handle backporting that for our customers

[00:22:02] Leo Dion (host): Oh, awesome.

[00:22:03] Sean Rucker (guest): in their own apps.

[00:22:05] Leo Dion (host): Before we close out, what would be like the top three features that you'd recommend developers or even designers look at when they first start Judo?

[00:22:18] Sean Rucker (guest): The first thing I would suggest they do is just start to familiarize themselves with the concept of SwiftUI views and modifiers. And we have great learning documentation. It's getting better every day. And so when you see the canvas, you start familiarizing yourself with that. You're actually teaching yourself SwiftUI.

[00:22:39] Sean Rucker (guest): You're not just learning a proprietary tool. And that's one of the things that I think is great about Judo. If you're a designer and you're learning Judo, you're adding to your resume. Because you're teaching yourself SwiftUI and an underlying framework. So that's the first thing I recommend they take a look at.

[00:22:56] Sean Rucker (guest): Second thing is the preview controls. So there's controls built into judo's canvas that allow you to simulate different scenarios like Light mode, dark mode, different accessibility settings, different languages, different device sizes. And so it gives these designers a sort of dynamic and flexible canvas that will adapt and show them how their designs will react.

[00:23:22] Sean Rucker (guest): So when you think about Figma or Sketch, you end up with this explosion of artboards where you say, Okay, here's what my design looks like on this phone screen. Here's what it looks like on a bigger one. Here's what it looks like in dark mode. Here's what happens if the user is German and the language gets twice as long and the button's got to truncate.

[00:23:40] Sean Rucker (guest): With Judo, you can design in one place and just toggle preview controls to see how everything adapts. And because we're built on SwiftUI, that, we get to take advantage of a lot of things like right to left languages, so the interface will just flip automatically for you and things like that.

[00:23:57] Leo Dion (host): Nice. That's awesome. Sean, thank you so much for coming on the show. Where can people find you and Judo online?

[00:24:04] Sean Rucker (guest): You can follow Judo on Twitter, at judoapp, and you can follow me there as well, at Sean Rucker, and check out our website, which is just judo. app.

[00:24:15] Leo Dion (host): Awesome. Thank you, Sean, for coming on. I really appreciate it.

[00:24:18] Sean Rucker (guest): Thanks for having me.

[00:24:20] Leo Dion (host): Yeah. People can find me on Twitter at Leo G Dion or whatever the heck it's called today. And then mass it on. I'm at Leo G Dion at C dot. I am. If you're watching this on YouTube, I'd love a and subscribe, please. And I actually have a really great article.

[00:24:35] Leo Dion (host): I'm going to post about some mistakes that designers and developers make, so definitely check that out as well. You'll see that in the show notes. Everyone have a good November and I will talk to you later. Bye everyone.