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