ruckstar

5 ms·

1.
by ruckstar 5y ago
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
2.
by ruckstar 5y ago
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.
3.
by ruckstar 5y ago
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.
4.
by ruckstar 5y ago
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 access
5.
by ruckstar 5y ago
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 bri
6.
by ruckstar 5y ago
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.
7.
by ruckstar 5y ago
SDUI :)
8.
by ruckstar 5y ago
A CMS (e.g. Contentful) provides the content/data. SDUI is about using that same technique for the layout of the user interface itself.
9.
by ruckstar 5y ago
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 impl
10.
by ruckstar 5y ago
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 cer
11.
by ruckstar 5y ago
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 implemen
12.
by ruckstar 5y ago
Ya, we've been using the term "server-driven UI" to explain what we do.
13.
by ruckstar 5y ago
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 cou
14.
by ruckstar 5y ago
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 i
15.
by ruckstar 5y ago
Great feedback, this is really helping us understand how to improve our messaging. The blog section in your app is a great use case.
16.
by ruckstar 5y ago
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...
17.
by ruckstar 5y ago
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 course
18.
by ruckstar 5y ago
Agreed. We have work to do!
19.
by ruckstar 5y ago
Right now we support iOS and Android. But we have Mac support on the roadmap.
20.
by ruckstar 5y ago
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 the
21.
by ruckstar 5y ago
Ya you got it. SwiftUI wasn't viable before Big Sur.
22.
by ruckstar 5y ago
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 f
23.
by ruckstar 5y ago
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/
24.
by ruckstar 5y ago
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 wou
25.
by ruckstar 5y ago
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/
26.
by ruckstar 5y ago
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 conn
27.
by ruckstar 5y ago
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