[bcardarella]

That's correct, but we can make changes to the views at runtime and these merge into the SwiftUI viewtree. That part has been working for years. As far as how we take the document and convert to SwiftUI views, there is no reflection in Swift or runtime eval. The solution is pretty simple: dictionary. We just have the tag name of an element mapped to the View struct. Same with modifiers.

[bcardarella]

As far as how it is different from React Native. That's a good question, one that I think is worth recognizing the irony which is that, as I understand it, without React Native our project probably wouldn't exist. From what I understand RN proved that composable UI was the desired UX even on native. Prior to RN we had UIKit and whatever Android had. RN came along and now we have SwiftUI and Jetpack Compose, both composable UI frameworks. We can represent any composable UI frameworks as a markup, not so much with the prior UI frameworks on native, at least not without defining our own abstraction above them.

As far as the differentiator: backend. If you're sold on client-side development then I don't think our solution is for you. If however you value SSR and want a balnance between front end and backend that's our market. So for a Hotwire app you could have a Rails app deployed that can accept a "ACCEPT application/swiftui" and we can send the proper template to the client. Just like the browser we parse and build the DOM and insantiate the Views in the native client. There are already countless examples of SSR native apps in the AppStore. As long as we aren't shipping code it's OK, which we're not. Just markup that represents UI state. The state would be managed on the server.

Another areas we differ is that we target the native UI framework, we don't have a unified UI framework. So you will need to know HTML - web, SwiftUI - iOS, Jetpack Compose - Android. This is necessary to establish the primitives that we can hopefully get to the point to build on top of to create a unified UI framework (or maybe someone solves that for us?)

With our wasm compilation, we may even be able to compile React itself and have it emit native templates. No idea if that would work or not. The limits come when the JS library itself is enforcing HTML constraints that we don't observe, like case sensitive tag names and attributes.

What about offline mode? Well for use cases that don't require it you're all set. We have lifecycle templates that ship on device for different app states, like being offline. If you want offline we have a concept that we haven't implemented yet. For Elixir we can just ship a version of the LV server on device that works locally then just does a datasync.

[wahnfrieden]

Apple allows shipping code over internet for many years now. They just don’t allow dramatically changing the purpose of the app etc

[bcardarella]

Apple also doesn't allow JITs, and you cannot hot load code to modify the application.

[mac-mc]

You can if it's javascript, and this sounds like a bunch of "Server Side UI" type of projects that many large tech companies end up starting.

[wahnfrieden]

Or any WASM-target language

[syndeo]

I've heard a blind eye is turned to React Native code changes, as long as it's not something drastic (or outright malicious like Epic).

[wahnfrieden]

You don't need JIT to hot load code. That's irrelevant.

And yes you can hot load code to modify the application. As long as you don't alter the purpose or scope of features under review. There is a specific callout as well that you can dynamically load in "casual games" from a community of contributing creators.

You're repeating outdated nonsense from over a decade ago! Understanding current App Store guidelines can be key for finding competitive edge when there are so many like yourself who scare devs off doing things that Apple now allows.