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.
Sean Rucker (guest): Thank you for having me
Leo Dion (host): Sean works with Judo, which is a app
that's currently in beta, right?
Sean Rucker (guest): We're in a soft launch phase.
We'll call it.
We'll call it
Leo Dion (host): launch.
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.
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.
And sometimes I call myself a product manager as well.
So I wear a lot of different hats on different teams.
And, yeah.
Leo Dion (host): That's interesting.
So you've done some design work as well.
Any apps that we would know about.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
Leo Dion (host): what do you think are the key parts of that we're missing?
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.
Leo Dion (host): Got you.
Okay.
Sean Rucker (guest): yeah, SwiftUI is so much faster for
building a user interface.
It's so much more resilient and stable.
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.
Leo Dion (host): So what are some other major things you learned about
SwiftUI and what goes on underneath with the development of Judo?
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.
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.
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.
Which...
Seems backwards but when you're really performance constrained,
that's just what you have to do.
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.
Is it still an issue there or is it like not so much
compared with the way iOS works?
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.
There's just a lot more going on in a Mac app and performance
is especially important there.
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?
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.
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...
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.
Leo Dion (host): wHat were some of the features that you've seen people
request that you were surprised about?
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.
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.
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.
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.
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.
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,
Leo Dion (host): How do you avoid scope creep where you're
essentially rebuilding X code?
Inside Judo,
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.
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.
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
Leo Dion (host): What's your minimum version right now?
Sean Rucker (guest): Right now it's 12.
Leo Dion (host): Oh, okay.
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.
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.
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.
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
Leo Dion (host): Oh, awesome.
Sean Rucker (guest): in their own apps.
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?
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.
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.
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.
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.
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.
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?
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.
Leo Dion (host): Awesome.
Thank you, Sean, for coming on.
I really appreciate it.
Sean Rucker (guest): Thanks for having me.
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.
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.