Show HN: Judo - Build Native App Experiences with No Code(judo.app)
judo.app
Show HN: Judo - Build Native App Experiences with No Code
https://www.judo.app/
64 comments
You're thinking bang-on about the product and where we're going.
Regarding design systems, we have a feature coming that we're either calling Components or Symbols (Sketch's term), we haven't decide which yet. The idea is to package up a configured set of layers into a saved "thing" that can be reused across your experiences. For example a standard button made up of a rectangle, image and text. Designers/builders can then use this button anywhere in their experience and override the value of the text while retaining the style (size, color, font, drop shadow etc.).
Custom data is supported today! You can pass information you know about the user locally to the SDK and use it to personalize your experiences. In the Mac app you can also supply sample user values in the Document Inspector to preview how your personalized experiences will look when viewed within your app by a real user. After adding sample values in the Document Inspector you can use {{user.}} to insert those values into your text layers.
For custom components, you could either build them as Judo components/symbols when they come out. We have also floated the idea of inserting placeholders in the Mac app which are replaced with your own custom components when rendered in your app. Although we haven't fully thought through how this will work yet.
Custom actions are supported today through URLs with custom schemes (aka deep links). You can attach an action to any layer in Judo and supply a custom URL you want it to open when the user taps it. We are expanding on what you can do with buttons in an upcoming release so more to come there as well.
Regarding design systems, we have a feature coming that we're either calling Components or Symbols (Sketch's term), we haven't decide which yet. The idea is to package up a configured set of layers into a saved "thing" that can be reused across your experiences. For example a standard button made up of a rectangle, image and text. Designers/builders can then use this button anywhere in their experience and override the value of the text while retaining the style (size, color, font, drop shadow etc.).
Custom data is supported today! You can pass information you know about the user locally to the SDK and use it to personalize your experiences. In the Mac app you can also supply sample user values in the Document Inspector to preview how your personalized experiences will look when viewed within your app by a real user. After adding sample values in the Document Inspector you can use {{user.}} to insert those values into your text layers.
For custom components, you could either build them as Judo components/symbols when they come out. We have also floated the idea of inserting placeholders in the Mac app which are replaced with your own custom components when rendered in your app. Although we haven't fully thought through how this will work yet.
Custom actions are supported today through URLs with custom schemes (aka deep links). You can attach an action to any layer in Judo and supply a custom URL you want it to open when the user taps it. We are expanding on what you can do with buttons in an upcoming release so more to come there as well.
This all sounds great, thanks for the additional info!
> For custom components, you could either build them as Judo components/symbols when they come out. We have also floated the idea of inserting placeholders in the Mac app which are replaced with your own custom components when rendered in your app. Although we haven't fully thought through how this will work yet.
While I'm sure just building these as Judo components would be quicker, I must give a strong +1 to the placeholder concept. Just thinking about our product card component, there are 3 different interactions, 10+ different visual parts, it's a core concept repeated throughout the app, there are lots of analytics things tied to it, and it has been optimised a fair bit. I don't think we can reasonably expect to rebuild a version in Judo that meets our needs, and I think that would be misusing Judo for things it's not really designed to do.
> For custom components, you could either build them as Judo components/symbols when they come out. We have also floated the idea of inserting placeholders in the Mac app which are replaced with your own custom components when rendered in your app. Although we haven't fully thought through how this will work yet.
While I'm sure just building these as Judo components would be quicker, I must give a strong +1 to the placeholder concept. Just thinking about our product card component, there are 3 different interactions, 10+ different visual parts, it's a core concept repeated throughout the app, there are lots of analytics things tied to it, and it has been optimised a fair bit. I don't think we can reasonably expect to rebuild a version in Judo that meets our needs, and I think that would be misusing Judo for things it's not really designed to do.
Thank you for this feedback! I'm gonna bump the priority of the placeholder feature in our roadmap. I think the use case you're describing is a very common one. Judo experiences integrate themselves seamlessly into your app in certain places where it makes sense. I think it's equally important for it work the other way around as well. I.e. parts of your native app should be able to integrate seamlessly within a Judo experience where it makes sense. Basically your view hierarchy should be able to mix in and out of Judo experiences depending on the use case.
I should also add, for your question about custom components, if you build them in Judo, they can be connected to your own APIs via the DataSource, Collection and Conditional layers. It's not super intuitive atm but we have a video course on how it works dropping next week. In the meantime, if you want to try out data sources and get stuck, let me know and I can walk you through it.
Is CX the new word for UX? Took me a minute to figure out what "We put the X in Mobile CX" meant.
I've heard people not wanting to call customers "users" but haven't come across it yet. IMO it only makes sense as a distinction from the end-user. Otherwise user is already well embedded in our language (username, user interface, user manual, etc).
I've heard people not wanting to call customers "users" but haven't come across it yet. IMO it only makes sense as a distinction from the end-user. Otherwise user is already well embedded in our language (username, user interface, user manual, etc).
Not sure we're in line with the rest of the industry but we use "users" as a general term and "customers" to refer to those who have placed an order with us at any point. That distinction can be quite useful when discussing user/customer journeys.
I'm seeing a lot of HN lauch posts with "book a demo" link instead of a demo video or demo app or pricing page. Why is this becoming a trend?
I don't know but if any YC startups get away with that on HN, please let me know at [email protected] because I'm telling them all not to do it.
As someone who practices Judo (the martial art) this made me very confused.
FTW Maximum Efficiency with Minimum Effort
I'm totally on board with applying the principles of judo, such as Seiryoku-Zenyo (the efficiency principle you mentioned), more widely than throwing people into a mat while wearing a particularly sturdy bathrobe.
But I'm not going to lie, seeing it used like this makes me cringe.
But I'm not going to lie, seeing it used like this makes me cringe.
Playing the devil's advocate here. But what problem is this product trying to solve. Completely unclear. Is it by reducing development needs?
I've only read the marketing page, but I'm thinking of it as less of a no-code app builder, and more of a smarter-than-average CMS. If you can hand off a whole section of your app to a content or marketing team to handle that's quite a boost to velocity.
Ya, we've been using the term "server-driven UI" to explain what we do.
Is there a showcase of live apps that are built on Judo?
There's no code just like serverless apps have no server.
There is still code. You just no longer control it. If it doesn't work the way it needs to, you are completely fucked.
There is still code. You just no longer control it. If it doesn't work the way it needs to, you are completely fucked.
OK I have to know - what framework did you use to make your front end landing page? It's absolute beautiful.
I'm guessing React?
I'm guessing React?
Where's the "Show"? It would be useful to have a straight link to an immediately useable instance.
File -> Share -> Airdrop is the closest thing I have found, I am sure a preview is in the works ...
Ya right now sharing to your iPhone with Airdrop is a good workflow. You can also send experiences via iMessage and it will open directly in iMessage because we implemented the QuickLook extension.
Also, we are currently working on implementing the FileProvider extensions on macOS and iOS which will facilitate automagically syncing between your Mac and iPhones. This will make it really easy to share experiences with everyone on your team.
Also, we are currently working on implementing the FileProvider extensions on macOS and iOS which will facilitate automagically syncing between your Mac and iPhones. This will make it really easy to share experiences with everyone on your team.
Can Judo build native desktop apps as well or just mobile apps?
Right now we support iOS and Android. But we have Mac support on the roadmap.
Just curious, would it be Catalyst based? https://developer.apple.com/mac-catalyst/
We are planning full Mac support for Mac apps that are built with SwiftUI. But if your Mac app is built with Catalyst it may very well work today...
Oh boy, the IJF is going to have an epic hissy fit
If you thought they were overreacted about leg grabs, wait until they see this.
So... this is a sdk + platform that basically downloads a "description" of an app onto the device, then builds a UI based on that description?
Is this actually positioning itself to be a realistic replacement for production ready native apps? Or is this just meant to be a rapid prototyping / 1 use throwaway apps?
From the use case it seems one could use Judo for specific parts of an app, for example, a user onboarding flow, together with A-B testing, while allowing the rest of the app a native build?
Is this actually positioning itself to be a realistic replacement for production ready native apps? Or is this just meant to be a rapid prototyping / 1 use throwaway apps?
From the use case it seems one could use Judo for specific parts of an app, for example, a user onboarding flow, together with A-B testing, while allowing the rest of the app a native build?
Judo is meant to integrate into your existing iOS and Android app. It's not an "app builder" platform. Instead, Judo facilitates server-driven UI for parts of your app where it makes sense. Typically areas that are displaying lots of data driven content and/or benefit from rapid iteration. It's also a great fit for ephemeral marketing content that doesn't make sense to be built by hand and go through a full release cycle.
Is the title is misleading? It sounds like it's a tool to build server-driven components for your native app?
It's both a no-code tool for building native mobile interfaces AND a platform for hosting/serving them remotely (i.e. server-driven UI). It doesn't make sense to use this for your entire app but it's an invaluable tool for certain use cases.
We're still playing with our marketing language. Very interested in feedback on how you'd position this.
We're still playing with our marketing language. Very interested in feedback on how you'd position this.
I was quite confused as well. I assumed from the beginning that this was a tool for building a whole app, and I was confused about why there was no App Store/Play Store process involved, and how any backend logic would work.
What I understand now, and where I see the value, is in this being a low-logic CMS – i.e. you can do a lot more than a flat article, but you likely wouldn't build a full app with it.
I can imagine us (as an iOS team) adding this as our Blog section in the app, and handing over responsibility for all the design, navigation, interaction, and articles, in it to our content team. They might even make our article much more interactive with this (quiz idea is great!). Currently they use a regular CMS for posts and we handle all the information hierarchy which isn't ideal.
What I understand now, and where I see the value, is in this being a low-logic CMS – i.e. you can do a lot more than a flat article, but you likely wouldn't build a full app with it.
I can imagine us (as an iOS team) adding this as our Blog section in the app, and handing over responsibility for all the design, navigation, interaction, and articles, in it to our content team. They might even make our article much more interactive with this (quiz idea is great!). Currently they use a regular CMS for posts and we handle all the information hierarchy which isn't ideal.
Great feedback, this is really helping us understand how to improve our messaging. The blog section in your app is a great use case.
I registered on the website, got pretty confused by the fact nothing tells you how to create an experience.
Nowhere there is a link to the editor app. The link is on the homepage but the homepage redirects you to the control panel if you are logged-in so you have to open an incognito session.
Once you have the incognito session, you can find a download link, but it opens the App Store, which requires an account, which requires a bank card to download.
Is there a .dmg somewhere ? (I cannot use the software due to that, Apple keeps rejecting my bank card, but it's a bit sad because I'd like to try).
Also, where is the pricing ?
What if your servers are down ?
Once you have the incognito session, you can find a download link, but it opens the App Store, which requires an account, which requires a bank card to download.
Is there a .dmg somewhere ? (I cannot use the software due to that, Apple keeps rejecting my bank card, but it's a bit sad because I'd like to try).
Also, where is the pricing ?
What if your servers are down ?
Yeah… anytime I don’t see a pricing page but see a “book demo” link I immediately stop navigating and move on.
There will be self-serve pricing coming very soon. In the meantime the product is free to use. Feel free to reach out via our contact form if you want to discuss pricing sooner.
https://try.judo.app/contact-us/
https://try.judo.app/contact-us/
Good feedback. We're still ironing out the onboarding UX. In the meantime, this getting started page should help:
https://try.judo.app/getting-started/
https://try.judo.app/getting-started/
You don't need a payment method to download free apps from the App Store.
When I created my Apple ID ~6 years ago, it forced me to enter my CC info before installing any new apps (even free ones). Is this not the case anymore?
not sure about now, but there was some really roundabout way to do this.
It depends on the country I guess, skipping credit card details page forces me back to the account registration step.
check Learning section: https://vimeo.com/judoapp it's full of short video tutorials you can start with. The app is available in AppStore for free
Where's the documentation? I can't figure out how to use a data source. I've been able to add a collection to it and set the path to the array in the API response, but how to I render data from the collection?
Edit: Figured it out. It uses double brace syntax, e.g. {{data.email}}.
Edit: Figured it out. It uses double brace syntax, e.g. {{data.email}}.
Glad you figure that out :) We have a video course dropping next week dedicated to DataSources and Collections. In the meantime, you can take a look at this example experience which makes heavy use of DataSources and Collections. It is connected to a Contentful API.
https://www.dropbox.com/s/owi4g0kgl7o4pej/FitnesExperience-D...
https://www.dropbox.com/s/owi4g0kgl7o4pej/FitnesExperience-D...
Just FYI.
Not sure about others, but I almost never watch video content to learn how to do something with a computer. I don't like needing to have audio turned on, they are often either too slow or too fast, and they don't allow me to move at my own pace / jump around as easily.
Video is a great medium to convince me to try something or show me why I should do something a particular way, but not the medium I want to use to learn how to use a thing generally. Really prefer text and occasionally text+picture.
Not sure about others, but I almost never watch video content to learn how to do something with a computer. I don't like needing to have audio turned on, they are often either too slow or too fast, and they don't allow me to move at my own pace / jump around as easily.
Video is a great medium to convince me to try something or show me why I should do something a particular way, but not the medium I want to use to learn how to use a thing generally. Really prefer text and occasionally text+picture.
Good feedback, thanks for sharing. I have passed these comments on to Kevin the product specialist in the videos.
We have a new Learning Center section of the website launching soon that will organize all the content into lessons and courses. At that point we can include text and images as well. The Vimeo page is a temporary workaround until the Learning Center launches.
We have a new Learning Center section of the website launching soon that will organize all the content into lessons and courses. At that point we can include text and images as well. The Vimeo page is a temporary workaround until the Learning Center launches.
When will we be able to build native experience without apps next !!?
WYSIWYG editor for native development
what could possibly go wrong
what could possibly go wrong
Not purely WYSIWYG because you can't arbitrarily place anything anywhere. It seems to be based on SwiftUI and carries over a lot of those concepts into the builder.
Exactly. We love SwiftUI's layout system. It has a learning curve but once you "get it" it feels so intuitive to build naturally responsive layouts.
Since our SDK is rendering native SwiftUI we decided the best experience would be to surface the API of the underlying layout system in a visual way. Similar to how Webflow surfaces HTML/CSS.
Of course this meant building a SwiftUI renderer for our Android SDK. We are considering a future release where the Mac app exposes both SwiftUI and Jetpack Compose to allow a full visual build experience that is 100% native to both platforms.
Since our SDK is rendering native SwiftUI we decided the best experience would be to surface the API of the underlying layout system in a visual way. Similar to how Webflow surfaces HTML/CSS.
Of course this meant building a SwiftUI renderer for our Android SDK. We are considering a future release where the Mac app exposes both SwiftUI and Jetpack Compose to allow a full visual build experience that is 100% native to both platforms.
Is there a reason the desktop app requires Mac OS 11?
I'm interested in this area as marketing teams do need to create ephemeral apps every now and then. One of my favourites is the Nike Lookbook App of 2015; by far one of the best and most visually creative things I've seen. Unfortunately it was removed from the app store.
https://news.nike.com/news/tech-book
I'm interested in this area as marketing teams do need to create ephemeral apps every now and then. One of my favourites is the Nike Lookbook App of 2015; by far one of the best and most visually creative things I've seen. Unfortunately it was removed from the app store.
https://news.nike.com/news/tech-book
You could build the entire Nike Lookbook as a Judo experience and deliver it through the primary Nike app. This is one of our most common use-cases.
Marketing teams often want to build engaging experiences like the Nike Lookbook and use them to engage with their core app audience. But an experience like this is ephemeral—it's only relevant for a short period of time. It wouldn't make sense for the core engineering team to build it by hand. By the time it made its way through the app release cycle and (hopefully) users updated to the new version of the app, the experience would no longer be relevant. And you'd need another app update just to remove the code they wrote for the experience.
This is a great use case for server-driven UI. Judo enables teams to design, build and deliver experiences like these through their native apps without writing code and without having to release an app update.
Marketing teams often want to build engaging experiences like the Nike Lookbook and use them to engage with their core app audience. But an experience like this is ephemeral—it's only relevant for a short period of time. It wouldn't make sense for the core engineering team to build it by hand. By the time it made its way through the app release cycle and (hopefully) users updated to the new version of the app, the experience would no longer be relevant. And you'd need another app update just to remove the code they wrote for the experience.
This is a great use case for server-driven UI. Judo enables teams to design, build and deliver experiences like these through their native apps without writing code and without having to release an app update.
"Judo is a Mac Application," so Mac only
editor is Mac only. SDK to "run" created experiences is for iOS and Android.
We're all SwiftUI, so while creating each bit of this isn't a lot of work itself, we need to add it to our API, backend, CMS, editor, database, etc. The more control we can give them over all this the better.
That said, there are things where we (as an engineering team) still need some control. Device support, accessibility – I can see these are fully supported and can be previewed, that's great! A few things that look missing that it would be good to see:
- Design system/styles/etc – we have a set of styles, colours, typefaces, padding sizes, etc that we want to use and/or strongly encourage.
- Custom data. We'd like to be able to pass in details from the system, like who's logged in, name and other user properties that matter in our product.
- Custom components. We have things like a product card component that it would be great to be able to re-use here. How that would get its data though... not sure.
- Custom actions. I can see something about this in the app but not sure how it works. We would want to be able to link to places in the app, ideally with URLs, and have responsibility of presenting that UI handed back to the non-Judo part of the app.
I may be assuming a lot about the product here, maybe this isn't the direction you're thinking, but I'm generally excited by this and keen to see how it develops over time.