Hybrid Apps vs. Native Apps | feat. Ray Deck

interesting topic, and that is hybrid development versus native development. And many people think FlutterFlow, React Native are native development forms. And then if you look at something like Capacitor or Despia or all the other ones, that is not native. But the way I look at that is— and that may be a hot topic— all this, like Capacitor, Despia, React Native, FlutterFlow, they are hybrid ones. And the native ones, that is Jetpack Compose and SwiftUI and UIKit. Now that's how I look at that when people ask, is it a real native app or not? Now you've been building hybrid applications and native applications, and I've, you know, I'm selling a SaaS that helps people build hybrid applications. So I think it's just a great conversation to have. Should people build a hybrid application or should they build a native application, and when should they do What for someone that has built everything like you and someone who's tried to sell people to go into a specific direction?

Yeah, cool, man. It's a topic I get a lot. I advise people who are doing SwiftUI apps. I do quite a lot. I actually use React Native quite a bit myself. I've worked with Flutter and also with Capacitor. I remember Capacitor in the very early days back before it was Capacitor. Actually, some of the folks from Ionic, people who made Capacitor, they got bought out by OutSystems and then some of them even went on to work for Xano. I knew a couple of those.

I wanted to say, wasn't that the downfall of Capacitor? But that wouldn't be nice to OutSystems. Now more enterprise. It's now you need to hop on a meeting before you get that native feature added.

Yes, although Ionic was kind of heading that way anyway before the acquisition, if I was calling correctly. And that's just sort of the way, like, you know, software companies go, right? Like, you've, you've got your, you know, your self-serve business, you have your enterprise business. It's a lot easier to make more money with enterprise than it is with self-serve, and such was the way of them as well.

Yeah, wonderful. So now let's say we have someone watching here who wants to build a mobile application. They say, I have this business idea. What should they do? What is the best way? React Native, uh, FlutterFlow, WeWeb?

What should I—

Bravo Studio, which also has an interesting way of composing it together, because if I'm not mistaken, they do native development using web components.

Well, right, they, they, they— you can compose web components. They will then render onto the screen using their, their Bravo render engine, which is then being backed by Bravo. But really, like, Bravo Studio is, um, well, actually it's a little bit more like Despia, um, and, and sort of the hybrid approach that way with the old school Capacitor, in that it's streaming the app, right? So Bravo actually runs all the code on its servers and then streams it to the app that's running locally, right? So you get your JavaScript, whatever, that's what you're actually interacting with. Similarly, something you build, say, in WeWeb or Wiz or Nordcraft, or, or Loveable for that matter, and then you are— which is a web page, right? And then that web page is being streamed to your app through Despia. That's also a thing. And in both cases, really, if you don't— if you lose your connection to the network, you're kind of done.

Uh, that's just going to add offline support so you can export your whole file, and when you're offline, it syncs the state and catches all the variables. And then you have a whole offline experience that can store something into a local database, and then when you're back online, it'll execute the certain calls in the events even in the background. But it was certainly something my team hates me now for wanting to add that, because they're like, is this— you know, we're doing an app in a WebView. I was like, sure, but we can try to make it possible. We made it possible, but they— I don't know, they haven't talked with me since a week.

So, um, it is a technically very challenging thing to get a web page to work offline at all. Uh, and the— and I've done— I've actually made— I've made apps, hybrid apps that will— I've made a full Swift app that then was a wrapper for a WebView. I did that like whenever, like 12, 15 years ago, and it worked well. Um, I gotta say, like, that, that technology works relatively well The trick is the feel of the app is the feel of a web page. Back in the day, web pages running on mobile were very different from native apps. I think that the web browser, the web renderer has gotten a lot better. You notice less of that, although it's still not quite top-notch. Then that becomes, I think, the main argument for why you want to build, given the same app, why you'd want to build it native versus through streaming the web interface. Then there's next level up. We talk about hybrid apps and there are apps that use some JavaScript to them. Well, Flutter does not use JavaScript. Flutter uses its own language called Dart and compiles into each of these two environments. Compiles into iOS, compiles into Android. It really is Android first, it's a Google initiative and it works okay.

I would say it's sort of consistently been, you know, second fiddle to React Native in the, um, you know, in, in, in, in the space that you would say that because for performance I would always prefer Flutter over React Native. Like if you need animations and have lots of stuff on the DOM because I feel like the JavaScript overload that you're getting from React Native is a little bit more heavy than like Flutter Flow or Flutter?

Well, Flutter compiles to the, uh, you know, compiles down to their, their, the individual environments, and that works better. It certainly works much better in Android because it is sort of Android native in the way that it approaches the world. Um, I, I actually think the big advantage of Flutter that Flutter has right now is in Flutter Flow. Yeah, uh, that as a no-code environment, or rather, you know, it's, it's one of the most advanced low-code environments, is Flutter Flow. And the, um, it's a good way to make an app that can be cross-platform, etc. And it's built on top of Flutter. You can use Flutter code, but most importantly gives you access to this, you know, visual development plane that I think is, is pretty good about it. Um, there was a company called Draft— or it may even still be around— so-called Draftbit.

Um, they're still relevant.

There's— well, they're— they still exist anyway. Um, but I think in the world of React Native development, I've actually found that is not— the no-code is not the main way I'm seeing, uh, React Native work done. I'm actually seeing it much more through vibe coding. Yes. Uh, and that's because like Bolt has support for it. I don't know if Lovable does right now. Um, but, but like, you know, it, it's because, uh, React Native is built on the same bones as React and the code looks a lot like React, it's, you know, the AI that's been trained on the huge amount of React code that's out there in the world is actually leveraged that for React in a way that like there's a lot smaller corpus of Dart code in the world, which means that that the AI is not nearly as good at doing Flutter as it is doing React Native. React Native, the bones of React Native, like the team over at Expo, which largely runs it now, used to be mostly a Facebook initiative. They're really good and it's good stuff, it's strong. You were talking about the animations. I think the Reanimated framework that at one time was more of a plugin and now is really center of gravity makes it very smooth, first-class experience. Now it's got more support for SwiftUI in terms of the way it compiles down. Yeah, but the way it works is it is a native— it's a native system that runs, you know, native components, kind of like what Flutter does. And then it has a JavaScript— uses a JavaScript engine, right, to actually run the business logic, which is kind of what I find to be kind of clever. That way, that thing is sort of deciding in a React style, diffing the— what's available on the page, what needs to change, what animations need to be triggered, bing bing bing. And then it just works, and that's been pretty impressive as well. I really like React Native. It's my go-to for doing a lot of mobile development, even when I'm doing single-platform development. Then the final would be like what you're calling native development, and that's going to be using Objective-C or Swift on the iOS side, using Kotlin or Java on the Android side, where you're making code that only works with one of those two environments, but also dealing with all the peccadillos of those environments. I think the biggest advantage of doing it completely natively is getting the completely native tools available to you. Things that are available or that work differently in one environment versus another, like the way augmented reality works, the way AI access works, the way you can keep on going with things that are specific.

eSIMs is actually the simplest example, like it's completely different on Android than it is on iOS.

Then of course the user experience can also be pretty smooth too. If you're going to make video games, there's really no way to do it. Doing it cross-platform is not really a great gig because you want access to all the power, so you don't want anybody to be sitting in between.

We have a great comment from Chris. He said, I wish PWAs were first-class citizens on mobile devices. Would just solve all the world problems.

I mean, they are with Despia, but you still need to use a PWA, right? You're just streaming a web page, right? You're not using real PWA features because Despia—

no, no, it's not. It's going to use the native engine, but you can build a PWA and then get it through Despia. And we're actually doing a lot of re-rendering and UI adjustments where when you usually like get a WebView and all that stuff. You can feel it's a WebView because every time you tap a button, there is this ugly tapping thing. The button turns blue for a second and then you can select random text. If you hold your finger on an SVG for 3 seconds, the whole app crashes. There's some weird stuff happening in WebViews. We're getting rid of all of that for you. You don't necessarily feel It doesn't give all the obvious hints, hey, I'm a WebView. We also have, of course, hardware acceleration, which everybody has now. It's not something to really advertise. But we also do caching. It's going to be way faster, way smoother. But ultimately, your UI is still in the WebView. Having 5,000 images on one page is not a good idea. You may want to think about virtual scrolling at that point. But you should also in React Native.

[Speaker] Over all these, you can't load infinite amount of data and then expect it to not croak. It's gonna be a— it'll be a bad day for somebody.

We got another comment from Chris. Flutter uses the Skia engine, which is ultimately just like a game engine. It's why you can paint anything.

Yeah, I mean, you get into the bones of these things, you're gonna find actually there's some really cool technology that's used by both these, uh, both these things. And, and like, the, uh, the, the, the, the stuff that you can paint with Flutter, you'd be really surprised what you can make Flutter a Flutter app look like. The question is how much work you're putting into making that Flutter app and making it work in your particular environment.

I think Flutter is probably the closest to HTML, CSS, and JavaScript just based on the flexibility that you can do with it.

Yeah, I think yes, it's very flexible.

I mean, WebView would be the closest, but for obvious reasons. But it's a second—

it certainly gives you a lot of, uh, a lot of visual control. And I think that was a key consideration, uh, when they were, when they were making it. Um, and that's— yeah, I mean, there, there's lots of, like, I mean, all the— just, you know, I think, you know, people talk about these things in like semi-religious terms, right? Like, but— and they'll also do like these association video— X is so dead and Y is so— you know, but, but they're all really impressive technologies. And, and my, my shorthand is, uh, PWA is probably fastest if you have a population of one, if you don't really care about distribution. The, uh, Flutter is probably best if you want to be using a visual control plane because of the FlutterFlow. I think React Native is really, really good, especially if you're going to be doing more of a, you know, be using AI-assisted development. And, uh, and then if you're looking to really dial in the control SwiftUI is so much easier to use than the way you used to develop in Swift using Interface Builder and the other tools available through Xcode, as opposed to what it looks like for the last 24 months versus what it looked like, say, 3, 4 years ago is just night and freaking day.

If you can understand JavaScript, you can understand Swift.

Because it's— they—

all the programming language nowadays are pretty similar. Well, like, you know, you gotta work type safety and all that kind of stuff, but like, they are all like— if you can under— if you can look at a piece of JavaScript and kind of like understand what it's doing, you can understand what a piece of Swift is doing. And The import statements are just looking different, but it's like, it's all quite similar.

I think that's, well, you know, I think that's true for Python. I think that's true for Java. I think that's true for JavaScript. I think it's true, certainly for TypeScript, which is very, which is built in JavaScript. Uh, it's true for Swift, less true for Objective-C. Objective-C is weird. Um, uh, Kotlin is pretty easy to read. Um, I think there are some languages that are just sort of have their own weird stuff, but most modern languages Right? Why would people— don't bring out new languages that have, you know, really weird argot to them anymore. It's a, um, you know, it's more an artifact of, oh wait, hey, we got to use the old language that looks more like C, right? Or what looks more like whatever crazy person decided to start making variants on C in the 1980s over at— over in Cupertino, California. Um, because that's how old Objective-C is. All right, basically Objective-C was They all turned to what's called C++, which was the other more popular way of doing object-oriented C programming back in the '80s. Because Apple made that bed, it just keeps on going and going and going. But Swift, thank you, Chris Latner, Swift makes a whole lot more sense. But I also want to touch on the point that you just made and also the point that Chris just made in his latest thing. This best bits from the best UI libraries, I think that's exactly right. I also think it, it's a better way of thinking about the languages because all the modern languages are getting more, more or less legible. Uh, they use pretty much the same conventions. Maybe they use curly braces in one place and indentation another. Maybe they use, you know, callbacks or promises different ways, whatever. But the, um, but, but the point he's making about SwiftUI— SwiftUI, I'm pretty sure, was made by someone who used to work on the React team. And there's a reason why it looks so much like React in the way that it got built. And like, it just sort of shows that the power of JavaScript isn't JavaScript, it's React. And that these libraries can do a lot more to teleport usability and speed of development than the underlying language does, right? It's not about JavaScript versus Swift, it's about React versus SwiftUI. And when you look at that second comparison, it's like, oh, Oh, hey, yeah, if you get one, you can kind of get the other. And like, there's just a lot of value there.

Yeah. And I also think people are thinking that when they are choosing right now something to build an application, they're thinking, how can I build an application on something that will last me the next 10 years? No application ever lasts that long. It's like, you should think, how can I build something that will last the next 5 weeks, you know, and then in 5 weeks, once you got some traction, you'll reconsider what you're using. It's not a decision that you have to make and die with, right?

This is the point in the episode where I break out my catchphrase.

You will build this again.

I appreciate that, man. Thank you. Yeah, that is— that's just—

I mean, unless you use Bubble or some other no-code tools because they don't give you your keystore, so you got to restart over for your Android.

Well, and I think there's not— that's not the end of the world either. You know, you just keep on rebuilding. I was just doing an onboarding call for StateChange, uh, shortly before this, uh, somebody who's I think in your community. And, um, I was advising the whole 'you will build this again' mantra, uh, and the individual was not super thrilled with me for it because they had already rebuilt a whole bunch of times. But the— but I said that that's okay, I get it, you built a whole bunch of times, you're gonna rebuild a whole bunch more times.

I, I told, I, I told the same thing today, and I've been telling it the whole time. I said, you're, you'll start in WeWeb, then you'll go to Norcraft, you go somewhere else, might as well be in Lovable at some point. We don't know.

And yeah, the, the, the, the other thing I was saying in that conversation, I'll also say here, is that the, um, you know, the, the AI support for these tools is changing by the day, and, and almost uniformly for the better. The wait, I tried that 6 months ago and it just didn't work with SwiftUI or whatever, but totally encourage trying it again because these things just work.

I remember I have many people that say, I don't like Lovable. I tried it. I said, okay, what did you build in Lovable? They were like, yeah, I tried half a year ago. I was like, yeah, but have you tried it today? It's different today than it was half a year ago. They said, yeah, I tried it yesterday. Some said I tried yesterday. I just don't like the UI. I said, how long did you spend time prompting? They're like, yeah, I did like 2 prompts. I was like, Yeah, but did you tell it how you want it to look? You can't just go to AI and say, make something nice. Uh, it's going to— it's just going to do something what the AI thinks is nice, but AI doesn't have feelings. You gotta add some photos in there, some links, some references. Look on npm for some nice UI frameworks. What configuration of ChatGPT do you want? Paste some components in there, right? Like, just because I think people have a hard time understanding, like, especially when they come from no-code. Like, in no-code, you have to put a lot of effort in to get something. And then when they go into AI, they feel like, now I don't have to do any effort and I expect the best results. No, you got to do both. You need to do some prompting and you need to do some effort. But Chris is completely right. I think Radiant is a very promising tool. That's how you funnel in some unpaid advertisement here.

Well, have you gotten to use Radiant yet?

My friend, I've been looking at their video presentations on X, so passively using it. I've looked at other people using it, and so far it looks like a very big pleasure using it.

Okay, the— yeah, I'll be looking forward to seeing how it is in, in action, you know. It's, it's all Yeah, it is easier to put together a demo that makes it look very good.

And then about that, for first 6 months of Despia, the thing was pretty much usable— unusable. But hopefully we can get access this week. I hope so too, Chris. If you get access, we got to share one account.

Um, yeah, yeah, I, I, I love going and checking out these new tools, you know, like the— I'd sort of see what, what's changing, um, among them.

Um, and then sort of, you know, there's also a very interesting vibe coding tool coming. I can sadly not talk more in detail about it, but they're actually going to integrate Despia's API for the iOS publishing and the Android publishing part of it. So they're kind of like lovable— like, it's similar to Radian, I would say, but, uh, focused on hybrid applications, which I think is very interesting. So I can't talk more about it, but, you know, they're going to— like, like you said yesterday, not Intel Inside, Despia Inside.

Yeah, yeah, the commercialization is a great— I, I love that as a business model. And the more you can put things together in a way that other people use it, that's That's just an exciting place to be.

Yeah, I definitely think when we are asking about native development, I think there are two stages of native development. There is building the application that gets you started and you're building the application that gets you from where you started. Most of the times, the— Chris said DM me, I'll DM you. But most of the times, when you are creating an application, your success is based on you getting across the finish line, just getting it done. Then after you have a million of users and your application crashes, you worry about some of the other stuff. But first, you never know if it's going to be successful if you can get it out there. I personally, and I'm 150% biased about this, I feel for me, the nicest way of building a mobile application is doing it on the web. It gives me all the flexibility, I can get all my questions JavaScript packages in there, just load random stuff inside of there and, you know, use some of the UI libraries. Then have it as a web app, as a PWA, and a native app, and then see which distribution method works well. Do I have more success on the web? Do I have more success on the App Store? There are some apps that work well on the App Store, some that don't work well on the App Store, that work better as a SaaS because it's part of people workflows, they want to do it on a computer or on an iPad or something like this. Again, completely biased on that. But I do really like Capacitor-like native, hybrid native, web-to-native development. You can do cool stuff. You can fully hack that whole stuff together. That's what I like about it. For me, with React Native, I've tried React Native and Swift, of course, you definitely need Swift. But I've tried all of them. I feel like with native development, there are too many rules. And there's like a little bit less I can just hack stuff together where, like with web-based native applications, I can just load stuff in there. And I can just do very interesting stuff. I feel like you got like, you got more rules, and you got less rules, and more freedom in what you can do. And it personally, it allows me to move faster. I know there are people that are like me, I know people that are thinking, what the heck is he talking about? But that's just something that how I like developing my prototypes at least. Then sometimes it can go beyond a prototype.

Yeah.

The ability to just update something on your web app and have it updated on your mobile app, especially while you're testing stuff out without having to go through app review every time you do a change, that's pretty convenient. But you also do have that with React Native and Expo. You can use CodePush and all kinds of stuff. It's just a different process.

Yes. I would say creating for a direct web app is certainly a smoother experience than using CodePush or any of those other bits. I tend to just push directly through the App Store because the turnaround time for getting an update approved is like 6 or 7 hours. Um, it's just not, not usually that big a deal. If I'm looking to test something quickly, I can do that instantly through TestFlight. But the, uh, and then, you know, just sort of goes— well, I sort of got my 3 levels, right? Local dev, right? So push to my phone through just the wire. Um, you know, there's TestFlight, which usually takes, you know, minutes, and then, uh, pushing it through the App Store, which usually takes, uh, hours. And, um, and I, I really like the native apps. I like the, the control. I like the way they work. Um, and the— and, and, you know, my, my contribution to the world of React Native, you know, particularly like, you know, 7, 8 years ago, was I was connecting it with like the, the local AI systems. And that's something that really does require having access to the native runtimes, right, if you want to be able to bridge to those systems. And actually, I, I— my general take is that making an app, uh, you are best off— and that's one of the reasons why Despia is actually pretty cool is allows you to have the simplicity of building a web app while giving you a bridge to access these, um, local AI.

Come next month as an SDK, JavaScript SDK, one-line JavaScript SDK. You're doing await Despia local AI colon slash slash query parameter with your user's question, and then under it you do const AI response, and then you can console.log it or get it back into your UI.

That's super cool. Yeah, the being able to connect that bridge is really valuable and I'm glad you've got that there.

I'm going to add all the sensors, NFC, local AI. Now one thing I'm really excited about is kiosks for Android so you can build custom launcher apps, so you can build the next Rabbit R2 if you want. It's something I'm going to make a video about, building the Rabbit R2, like, you know, like this scam device they sold, like the Rabbit R1. It became a whole flop, and like the founder turned out to be an ex-crypto scam person, and like, you know, the whole controversy about the thing. I want to make a video how I'm contacting a factory in China, getting the OEM product made, having them sideload the launcher APK up, and like having it shipped from China to me, and like make a video how I'm building my own Rabbit device. Hopefully don't get a cease and desist from them and then have a very entertaining YouTube video.

I guess we'll find out. But yes, I won't mention it.

There'll be a black bar over my mouth and some beeping.

Yeah, but I am— yeah, I look at mobile and say that the most exciting thing to do with a mobile app is to connect to things that are mobile. Centric. Otherwise, you might as well just— I mean, the, the, you know, Chris's comment from earlier, uh, you could just have like a PWA and then it's like, you know, you have PWA plus distribution, and that's not nothing. That's probably what most people are going to wind up using Despia for. Um, so how do I get speed of development? How do I get ease of distribution? Fantastic.

Um, you do though have to follow minimum functionality requirements, so you do need to have some native functionalities in there.

Oh, uh, yeah, take your point. Like, there are rules against like—

you can't just put a landing page on the App Store. Like, for that you can use AppMySite and get a rejection. Um, you know, because the App Store likes apps that actually provide value.

So if you don't mind my asking, like, uh, speaking of apps and app stores, um, you, you mentioned Radian a minute ago. One of the things I can usually count on you for is What else are you seeing this week in the market?

So I like Rayyan, and I've been seeing more of Rayyan this week, and apparently Chris too, because, you know, we got lots of comments about that. I'm very excited about it. I saw another no-code tool today in our community. It's called Luna Park, and it looks like someone just knocked off Nordkraft with an OutSystems vibe to it. You should look it up.

Luna Park.

Luna Park. Look it up. Luna Park. It's like Luna minus park dot com. No, dot app. It's, it's very— I think they should rebrand like Norcraft did, but, uh, they, they need it. Um, it's hard to find because there's like so many stuff on the internet called Luna and Luna Park.

Mm-hmm.

Let me pull it up for you. Yeah, it's like, it's like if you told someone, can you just make a copy of Nordkraft? And someone said yes. That's pretty much Luna Park. See my screen?

Yes, I do. We all do.

Okay, that's Luna Park. So pretty much is a— it's a visual scripting engine. And of course you have your elements, you have your events, you know, you can create your events. Let's do a click event, right? You can edit the logic and then you have your unmounted event, your onClick. You see it's pretty much like Norcraft. You can then do a console.log here. Look at that, Ray, we get console.log. You can just write something in there and you can put your object, you can do string and you can do an input for this, call it text. Essentially, it's like Norcraft, it lets you visually create those scripting, those formula. But it does— I don't know, it just has this OutSystems Mendix vibe to it. It's like, you know what I mean?

Why? Because the canvas?

No, it's just like from the— from how it looks, it just doesn't— like, Nordcraft looks more like self-serve, no-code, like WeWeb, Bubble, uh, you know what I mean? Where this It has this, we start at $5,000 a month vibe to it, you know what I mean?

Uh, it does. I think the corporate vibe you're talking about has to do with the fact they have tiny icons, uh, the little blocky, um, actually the fact that everything is tiny in order to get you more workspace. That's very much an engineering decision, um, which I actually think is kind of practical given what they're doing.

Yeah. What it is, but isn't that interesting? I think they kind of like got really inspired based on how Nordcraft does it with the notes, right?

Mm-hmm.

You got your data panel and all that stuff. I think very interesting tool to look out for, like Luna Park Visual Scripting Editor. All-in-one editor lets you build performant and scalable web apps visually, export clean code, and host it anywhere. So they have self-hosting out of the box. And they actually only let you pay for the editor.

I've been seeing that more and more. The, um, like the, the, the premise of a lot of loco tools was that, hey, you're gonna come in, you can use our build tool, which is gonna build into our environment, and then you're gonna use our environment forever and ever and ever, right? That's basically, I mean, that, that's Wiz story. That, that's also the Out story. That's also the Mendex story and whatever. Like you're gonna use our runtime and now you're gonna keep paying for our thing because. You now depend on using our—

we got away from that. They're now really encouraging people to self-host, which I think is very smart.

That makes it look much more like a Vibe coding tool. That is where— that's where B0 is, that's where Lovable is, that's where Bolt is. Um, that's, I think, where, uh, that's where VibeFlow is. I think that's where Manus is too. Um, and sorry, whatever it's called. Anyway, the, um, the, the idea is, uh, that you know, they're in the developer tool business and not in the infrastructure business. And now they get to not have to worry about infrastructure. They can just sort of provide you with stuff that works and is, you know, usable somewhere else.

And they can just give you a REST API to push it for you to GitHub or something, right?

Well, right. They can— you can just download it or they can make a hook to sort of push it to GitHub, which some of them have done, which is now GitHub's trying to make that easy because GitHub wants to be a place where all the stuff lands. So yeah, like everybody, everybody gets incentive. I think a one mark of good strategy in an ecosystem like this is to make a business that makes more money when the, the entities around you in the market are making more money. Yeah, because you can be a multiplier on their success. Well then everybody's sort of, you know, positively incented. I, I can't tell you how many of these I run into where it's like, oh hey, you should use us and not spend your money across the street. Well, that, that competitive sale is a harder one to make for people who are already using ThingCross Street.

Yeah, no, I think having— building a tool that integrates with everything, like if you build in Lovable, if you build wherever you're building, if you can sell people a tool that just they all plug into nicely, that's a great sale. That's why Xano has such an easy time selling to all no-code frontend users and React users and Angular users. I mean, if they're having a hard time in general selling to users, that, that of course they need to innovate a little bit more with AI. Got XanoScript implemented, they should have a Lovable integration, and Lovable should be willing to have Xano integrated in there. There is some work to be done, but, uh, you know, generally Xano is probably making more money than the frontend tools because they— because usually people start a frontend and that's just the easiest thing to start. And when you start building an app, most normal users start building the frontend because they think that's the app. They don't know that 90% of all the important stuff runs on the backend, and then they need a backend. And then no matter which frontend tool they're using, they're in the market for Xano.

I think that's true of the self-serve market, definitely. Um, the, um, the, the enterprise market, or even the, the medium-sized market, you usually are looking for a front end that's going to give you more leverage off of whatever you got going on in the back. And the, um, and that's— and I think that's going to be a key thing. Like, you're right, the entrepreneurs, hey, they need a back end. There are only a couple few options, but one of them, Supabase, which is pretty programmable. You have Xano, which is very good and gives you the, the local, the, uh, the no-code access, although its programmability is a lot less than, say, Supabase is because they, you know, they have not allowed programmability and they're going to be gating it through this, you know, XAML script thing. The, um, and then like what, Buildship, and, you know, maybe a couple, and like VibeFlow just came out, and, you know, maybe a couple others. The, um, the, the, the, the front ends are though are competing, and boy, they are able to sell a lot Like, I think the reason why Lovable has so much revenue is not because of people like you or people like me. It's because they are making these big corporate sales.

Corporations. I mean, right. I saw some people on X, like, I think it was Lovable CEO. He retweeted a job listing on LinkedIn where someone says, need to have experience vibe coding. And it was like a Fortune 500 company. And he said like, Fortune 500 companies are looking for Vibe Coders. Get your Lovable account. This is the future.

It is the future. You know, I was also talking, the person I was talking with earlier was saying that they were, uh, they did not consider themselves technical, right? They've been using low-code tools going from one to another, and they were sort of turned off by the Vibe Coding tools because then you have to look at the code. I actually think that same individual would have a much easier time today using, you know, using Lovable 6 months later. One, because Lovable's easier to work with. Second, The other thing that's really important is that these people are getting a lot more exposure to code and how a computer thinks. Like, oh wait, hey, that's just like that visual thing I saw last time. That's right. You're pressing it through text. There's a little bit of like, why can't it go back and forth a little more? Which is a hard technical problem but not an impossible one. It's just not that scary.

Yeah. Actually, while you were talking, I just vibed coding app and love Don't mind me, I'm just vibecoding an app.

Yeah, I don't know, but like, I've, I've used, uh, Cloud Code now a few times and I've one-shotted, you know, complete services I was able to deploy up to like, uh, Google Cloud Run to take care of an annoying— a single problem, but like an annoying, highly technical one. And It did a great job. I was able to show it up and was done with it. And, you know, sometimes there's silly, like, hey, this is gonna be done using React, using Node 18. Node 18, for those of you who don't know, is really quite old. So, like, let's use the current version of Node. And that— outside of that though, it was just ready to go.

Yeah, I mean, I found that AI is really good at taking outdated npm packages where the URL of the package doesn't even exist anymore. It just does very well. It just uses— I'm just going to use this link from Cloudflare when Cloudflare was still having a free-to-use public CDN. And you go on there and you're like, oh, they don't do this anymore.

Yeah, the 404ing of the web. You know, there's a great— have you seen the XKCD comic? It's a classic one at this point, like the world's, you know, electronic infrastructure that's riding on, heavily dependent on this, you know, one project somebody did as a side project back in 2003.

Oh, I saw that with like YouTube, Netflix, and all kinds of websites all on this FFmpeg.

That's also true. That's just, Yeah, uh, you know, it is crazy where those dependencies are. And the, um, but, but that's the reason why we sort of look at these different tools, try to get better understanding what's going on with them, and also like where, where, what really matters in the world of software. That's why I thought your initial topic was so good for us to get into today, right? Like the whole hybrid apps versus, uh, you know, the native mobile apps. Like, where's— which pieces of software matter? Not just how are we trying to build, but what are we trying to build.

Yeah. You want to see my vibe-coded app? It doesn't look pretty yet.

10 minutes. 5-minute app, we're going to see it.

Let's see. Let's go in here. You see my phone?

Yes, sir.

Look at that. Got my app. And I just wanted to see if I can have an app built in Lovable and if it understands some stuff. And it didn't get the CSS safe area quite right with the custom variable, but that's fine. And, uh, you know, I can just click on here, it runs my Face ID, and then when the Face ID was successful, it unlocks the hidden treasure. And I can just do payments. I got that integrated with RevenueCat. Look at that, you just do the payments. Let's do payment here.

Look at that.

And then I get the device ID and I can load my native contacts in the interface. I do request permission and then I read the context and I get my contacts inside of here. And I just one-shotted that in Lovable and it just took seconds to get it done, like maybe 1 or 2 minutes. And all the SDKs are all set up correctly. Which you couldn't do this half a year ago. I think the Lovable that we have today is completely different from the Lovable that we had in the future. Of course, you need to be really knowing what you want to do if you want to have a good interface because the interface I showed, it's a joke. But if you're willing to prompt back and forth, look up UI libraries on the internet that you like, tell it to use those, you'll be, you'll be very happy with the outcomes of it.

Well, if you wouldn't mind me just dialing into that a little bit, because I think that makes for a very good topic for us to talk about for a few minutes, which is this idea of giving it more direction, right? I think lots of people, uh, and in fact I was just having a conversation last night where my hackathon partner was saying, well, we should like give it broad instructions, let it figure it out. Okay, we can try that. And then you know what, it often sometimes does an okay job and sometimes it really does not. And so this is where like the point you were making of like, hey, which libraries do you want to use? Which constraints do you want to give it? I find when I give it those constraints, it stays within them, you know.

v0 just open-sourced their builder.

Okay, that's, that's a useful thing to know about. Oh, and actually what they open-sourced at least was there was the API for Builder, the idea being you can build your own Vibe Coding front end for v0, and then you pay them for their AI model. Uh, I, I think something along those lines. Yeah, you pay them.

You have that too. If you, if you apply that, Despia is now open source too. You can pay us. There you go. Now we could put open source. Open source is not protected terms. So that's why Nordkraft is open source, even though the editor is not open source.

Yeah, it's like, what are you trying to do with the open source part? What are you trying to do with the closed source part? I think there's a— yeah, that's just becomes the question is like, what is the job to be done? I think sometimes like, hey, the reason we have open source is so that if we go bankrupt, you can get it. I tell you, you don't need open source to do that. There's, there are licenses that will take care of that. Um, the, the, but the, but the local, but the, uh, open source is also, um, what we're trying to say here, um, the open source also is a way to sort of communicate, right, that other people can play with this without having to, uh, you know, uh, do more with it. Like, that's kind of what N8n is doing, right? And it's taking an approach like Community Edition is open source and then to encourage people to go build more stuff on it, which is actually— I mean, for a while they were floundering, but more recently, like with the whole, you know, AI turn and when they did the LangChain stuff, it, uh, it worked pretty well for them.

Yeah, I, I remember, and it has been out there forever, they're a dinosaur, but they were always like the wannabe Zapier, and now Zapier is like jealous of them. Chris said they open source the entire builder. They want more people to host stuff on Vercel, apparently.

Uh, which makes sense to me. Yeah, I need to explore more of that, the v0, um, you know, the, the v0 SDK. Right? Because I learned about the SDK part. What I didn't know is about— oh, actually, right, they have React, React tools, uh, for rendering the API Platform content. Well, that's for rendering the content. What I don't know is about rendering the, uh, the chat side of it. Uh, and certainly they have like examples, what have you, that are— that look pretty cool as well. So anyway, those things—

it's a clone.

You should—

maybe it's one of the Vercel starter templates. Who knows?

Yeah, the— anyway, but, but getting in the— the— for me, open source is really exciting also as a, as a consumer and as a hacker, right? To go get the stuff, to go play with it, to go learn from it faster, um, to get a better understanding about how these things really, um, really work so that you might be able to do other interesting things with it. Yeah, that got me into contributing to React Native.

That's what got me into contributing to some of these other things Yeah, and you know, everybody can be happy if you contribute to whatever they're doing because you're a genius.

So the, uh, but the, but, but can I ask you, actually, uh, just over the weekend I, I was pulled into helping someone up with an open source project, uh, sort of, who is, who's actually someone who works in the low-code space. So, uh, you know, Norcraft is doing that a bit. Yes, I realize, and it has had the open source for a while. Have you been experiencing much in the way of open source in the world of Lookout?

I'm not too much explaining open source because I remember when I talked with the Moment CEO, he said something I thought was really interesting. He says it doesn't matter really open sourcing runtime that is proprietary that only 10 engineers in the world understand.

Yeah, because this makes—

like, I was like, but then, you know, what if you're business goes bankrupt and then I want to self-host. And then he said, like, if we go bankrupt, why would you want to self-host the stuff that we built? Wouldn't you want to build your own? I was like, this makes sense. It's like, why open source something and, you know, that only 10 people in the world can truly understand on how it was built? Because it's not like those no-code tools give us pretty code. They give us code that looks like an alien. And then the engineer who was building this at 3 AM in the morning on 5 Red Bulls for some reason figured out how to put it all together and nobody really understands how he did it, you know. So I don't really see the value in open source low code. I see the value in bridging visual tools into open source frameworks like Radian is doing because it's fully React based. They are the first ones to have a visual React editor plus— Chris is saying the same thing. This turns out to start as a hidden infomercial for Despia and React Native, and now we're going to do a hidden infomercial for Radion. Look at that. But no, I think what you're doing is incredible. It's React-based, you own the whole code, but you have visual tooling to make the UI look exactly like you want and don't have purple gradients everywhere. I mean, if you want purple gradients, you can add them though, but I don't want purple gradients. AI wants purple gradients for me.

Yeah, AI does like its gradients. Uh, but yeah, the point about code from Radiant is also, I think, a good one too, because, uh, often I find that the code that comes from these systems, the putatively self-hosting code or whatever, it still looks like it was written by a Klingon.

I hope with Radian is going to change. And Chris is not affiliated with Radian, and I'm also not affiliated with Radian. I want to mention this. We're not being paid to set this. We're just excited.

And while I am not Ray— Radian, I am just— I'm just Ray.

That's why you should like it. They used your name for it.

I'm 40%. I'm 42% of the way to being radian. Just wait just 3 seconds. Yeah. Okay. This has been— this has been pretty good. Anything else we should cover before we wrap it up here today?

I mean, I think there is a major question that we need to answer because we kind of like went to a specific direction with the topic. Now, Ray, you've been doing this for 25 years— 26, 25 when I met you. Um, what is the best framework to build a mobile application? Like, maybe there are 3 categories of people trying to build a mobile application. What are those 3 categories that you see and stay changing all the time when you work with people? And which framework is the best for each of those people in that category?

Well, I think there are people who are trying to build, um, for people who— the people who want to build just a single platform, right? If you want to just build for iOS, uh, and I would say that, you know, SwiftUI has gotten good enough, uh, and gives you access to all the other stuff that, like, building directly in SwiftUI takes away— removes a lot of complexity, works really well as first first-party support from Apple. With the exception of the new Swift Package Manager, which is special.

It removes some of your old platform capability. You got to implement device checks. We have that error. If you migrate from UIKit to SwiftUI now and you use the latest build tools and all that, you're going to have some issues on iOS 16 or 14 with your app.

Uh, yeah, uh, well, I mean, there are all sorts of little individual technicals, but I was actually thinking a little bit more along the lines of like, you know, there used to be something called CocoaPods which is being deprecated, uh, and now, uh, the, uh, it's been replaced because Cocoa was for, for Objective-C, and then, and now what we've got is like SPM or Swift Package Manager, which is a little more immature. I think outside of that though, it's a really good environment if you're going to be doing something that's single platform, and Swift is not It's much easier to learn than it used to be. I think the biggest downside of working with Swift right now is that you have to write a lot more of it. The first— because almost all Swift needs to be done in Xcode, you're now limited to like the AI/VibeCode-y parts of Xcode, which is not supported on a first-party basis the way that say VS Code supports Copilot. And it is a little bit tougher. So that's something to give some thought to. The second, um, I, I think if you're going to be building a, you know, a cross-platform app or you're looking to be moving faster, especially if you have some, you know, React background to you, I love React Native. I think it's fantastic. Yeah, um, I would say that it is for me a really easy recommend, especially, uh, React Native plus Expo. Expo is the— is a toolkit to make it much, much faster to ship this stuff up to the App Store, uh, or to Google Play for that matter, its cross-platform capabilities are very good. Particularly if you have more comfort with a bit of code, there's a lot you can do that is for being able to extend it from just being a web app that's just being rendered using components to the rest. There's also something called NativeWin that's built into it, which gives you Tailwind type functionality, which is really convenient. The third I, I'd say like probably for a lot of people, if you're just going to be building an app for yourself, uh, or for a relatively small audience and you're building it for a web, uh, using PWA is the way to go. Uh, internal apps look like this, things that you don't need to worry about distribution through the App Store. And, and I think that probably there's a, uh, you know, if you are looking to have that level of simplicity, uh, and you want to be able to distribute to the App Store, that is exactly why someone should be looking at Despia, because allows you to take the simplicity of that which you might have built for one person or use as an internal app and be able to seriously consider bringing it to the rest of the world.

Yeah, and you get access to all native functionalities like you would have in React Native, just without the native components. You're just going to have one component, that's the WebView, for the interface rendering.

Oh, and, uh, and Chris has put into the chats here, uh, that Xcode does now have integrated with AI. Or rather the next version of Xcode has integrated AI, the so-called 26. Apple is renaming all their developer stuff.

What was it the last time I installed Xcode? Wasn't it like 14 or 16 or something like that?

This is like the way that we named everything 95— Microsoft named everything 95, right? And then they just did a whole reset and said we're gonna—

we're still at Windows 10, right?

And then they went back to them. Yes, so it was '95, Windows, uh, '98, and then Windows 2000. And then of course after Windows 2000 came, uh, Windows— what, Vista? Uh, followed by Windows 7, followed by Windows 8. Like they just gave up the ghost on the whole year thing, right?

It just doesn't matter. Like it just doesn't really make sense if you go from like '95 to 1.

Yes, it's all a little weird, but yeah, that's because Xcode 26 is intended for the 2026, um, uh, development. They, they're, they're trying— they're getting it out now because I think they want to have it out for Christmas. I think it's like the new iPhones, whatever, they're, they're coming out soon, are all using it. Um, and that seems like cool stuff, although I gotta say, like, the whole whatever it's called Liquid Glass thing in Xcode 26 Does seem nearly illegible. Yes, I think Chris is pouring one out for the homies, the Windows 2000 that we all know and remember and had terrible things to say about at the time. We all regret saying those things because then we saw Windows Vista that came afterwards.

That was beyond my time. But I did see some interesting memes. I think people compared iOS 26 with Android, not Android, with Windows. Was it Vista or something?

Who knows what it's all going to turn out as. We're just trying to make things go here. But anyway, I think it's a little bit about scale and how precise you want to be. One of the things I really like about, you know, uh, you know, Glide, for example— Glide for me really taught me what it meant to be a low-code application because you could build an application affordably for a single person.

Oh yeah, Glide is actually— Glide was my first step into no-code. I was probably one of their first users. I remember like it was like glideapps.com or something like this before they went like to Glide. Glide.com or glide.app, something like that. And, uh, I was one of their first users, I think one of the first few thousand. And back then it was still affordable, it was like $29 a month or so.

Yep. Right, they, like many others, went upmarket because that's— it's a lot easier to make money, make money charging more to a smaller set of people. And then that reopens up the self-serve market and the cycle begins anew.

Yeah, I think Glide is like everybody who considers building internal applications because you can build applications just for you. Like there's so much that you can automate with an application that is really nice. What I just wish they had more, I don't know if they added it, like more ability to run custom JavaScript in there. That would be nice.

I hear that, man.

Oh, one thing that you'll be appreciating is we're going to bring MCP support for Siri to Despia. So you can register automations using JavaScript that Siri can call in your web application.

Okay, I want to learn more about that. That sounds super, super cool.

So you can say like, hey Siri, order me my favorite coffee. And now— oh no, no, don't do it, Siri. And then it'll open your app and it'll run that. And What we're also going to have is we're going to have integration with the native Shortcuts app, you know, like the Shortcuts app of iOS. So whenever you get like a notification in your app, you can create a hook, like a webhook for your app, mobile application, where then it gets the data from the notification and creates a workflow with it, or it runs stuff in your app when you have an automation happening.

Super cool, man.

Native stuff, and it's all made in Swift. I like Swift. It's the only code I truly understand besides JavaScript. And AI is actually really good at Swift. I think it's better at Swift than at most other stuff, surprisingly.

All right. Well, I think that's an hour for us, man. We should definitely be doing this again next week. Wonderful.

It was a very exciting topic today, uh, about hybrid apps, React Native, and Flutter Flow is really getting carried only, uh, Flutter. Every time I want to say Flutter, I say Flutter Flow, and this pretty much proves the point I just wanted to make. You're using Flutter just for Flutter Flow. Wonderful. Thank you all for joining. It was very entertaining, and we'll do this again. Let's