ruckstar

Apple is more concerned with the code your app executes and especially that it does not change after it goes through the review process. From what I understand, they verify this by reviewing the set of system frameworks your app uses during the review process and then periodically checking this against installed versions of your app on users devices.

Downloading remote code from a server is different than downloading UI configuration. The code required for an SDUI implementation is contained within your app and goes through the normal review process.

Depends on the implementation. With a two-phased approach, the UI can be fetched remotely ahead of time in the background and stored on disk before the user needs to see it.

It's similar but in a format that is more conducive to rendering in the native frameworks on iOS and Android: SwiftUI and Jetpack Compose. HTML and CSS doesn't map very well to these native frameworks.

This is a solution for native iOS and Android apps. Rendering HTML within a native app has a ton of tradeoffs. SDUI is about bringing some of the benefits of HTML websites to native apps without compromising on platform features like accessibility, localization, dark mode etc.

Exactly. A website or web app can be updated as often as you want and you can be certain all your users will be seeing the latest version. Native apps have a different release cycle which brings unique challenges. SDUI is an approach to bring some of the benefits that web apps have to native. Of course you could just embed a web view in your app but then you lose out on a lot of things that make native great.

It's tough to get right, but very powerful when implemented well. It probably shouldn't be used everywhere but for certain use cases it makes a lot of sense and solves some problems unique to native apps.

SDUI :)

A CMS (e.g. Contentful) provides the content/data. SDUI is about using that same technique for the layout of the user interface itself.

Embedding a web view has a ton of tradeoffs. A good implementation of SDUI will support all the native platform features like accessibility, dark mode, localization. Not to mention the user experience is much more natural when the SDUI implementation is rendered using the same frameworks as the rest of the app.

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.

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.

Ya, we've been using the term "server-driven UI" to explain what we do.

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.

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.

Great feedback, this is really helping us understand how to improve our messaging. The blog section in your app is a great use case.

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...

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.

Agreed. We have work to do!

Right now we support iOS and Android. But we have Mac support on the roadmap.

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.

Ya you got it. SwiftUI wasn't viable before Big Sur.

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.

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/

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.

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/

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...

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.