Show HN: Judo - Build Native App Experiences with No Code
judo.app
judo.app
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?
We're still playing with our marketing language. Very interested in feedback on how you'd position this.
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.
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.
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.
> 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.
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 ?
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'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.
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.
But I'm not going to lie, seeing it used like this makes me cringe.
Edit: Figured it out. It uses double brace syntax, e.g. {{data.email}}.
https://www.dropbox.com/s/owi4g0kgl7o4pej/FitnesExperience-D...
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.
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.
There is still code. You just no longer control it. If it doesn't work the way it needs to, you are completely fucked.
I'm guessing React?
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.
what could possibly go wrong
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.