TLDR; LiveView is web only.

There have been efforts to make LiveView native, but it’s extremely difficult to do so, and thus far (to my knowledge) all have failed.

I was thinking about this the other day because carsandbids (Doug DeMuro’s car auction site) uses Blazor (at least as far as I can tell). And I think that’s one of its biggest advantages of Blazor—- is that it is capable of producing native apps and web apps while LiveView is resolutely not. And that’s because Microsoft can pay for it (or at least sponsor huge amounts of supporting infrastructure).

And FWIW— that’s an extremely difficult problem to solve. It requires an enormous amount of funding, both a huge team capable of both understanding Android and iOS SDKs and capital to employ folks on pure engineering challenges (hence why MS or Meta can). End users don’t care if it’s made with LiveView, Blazor, React, Java, SwiftUI, et. al. And, the list of companies that can facilitate that long term is extremely small.

There’s also the issue of OTP being non-trivial to implement or meaningfully transpile into another language/runtime. Erlang, BEAM, and OTP were made together for each other in a very peculiar and specific way, for a specific set of problems, and if it wasn’t a necessity that they were developed together it would be a dead language, runtime, and platform (and for the record it’s absolutely not).

▲

cpursley 6 hours ago | parent | next [-]

Why not just build mobile apps in their native language (Swift etc)? Anyways, end users absolutely notice and care - cross platform mobile apps are all hot garbage without exception.

	▲	epolanski 5 hours ago \| parent \| next [-]
		Especially now that you can likely throw the mobile conversion to an LLM and judge the feasibility of it's maintenance once it's done.
	▲	rubyn00bie 6 hours ago \| parent \| prev \| next [-]
		That’s what I would do that personally. I hate wrappers around native SDKs. But I also learned them. A lot of folks assume mobile apps are “difficult” because of the underlying language. But it’s not the language that’s an issue, it’s the SDKs. They’re so wildly different from each other, and the way things work on the web, that it’s (IMHO) a losing proposition to do so. That’s not to say things like Blazor or React Native don’t have a place but that place is one that’s inherently difficult to maintain without huge amounts of ongoing effort and capital invested in non user facing features.
	▲	5 hours ago \| parent \| prev [-]
		[deleted]

▲

cyberpunk 5 hours ago | parent | prev [-]

I am a fan of the idea, but the websocket is also quite a big attack surface; you can do a lot more by sending messages over this socket to your phoenix app than you would likely expect to have exposed via some api on another framework.

It’s difficult to secure, in my opinion. Perhaps not impossible but the cost of doing so pretty much eclipses the benefits of using liveview imo.

▲

mcintyre1994 5 hours ago | parent | next [-]

I haven’t used it for anything in production so I haven’t seen these issues, could you give a bit more detail? I’m mostly wondering why you’d have any more websocket messages that you respond to than you would APIs if you were using any other approach. Does LiveView itself respond to certain messages bypassing your app?

	▲	GCUMstlyHarmls 3 hours ago \| parent [-]
		There is some propensity to forget that you're basically making a REST API because its all "in my process, responding to messages", it feels like you're writing your regular server side render controller. But really instead of `PUT /create/post` its `websocket.send("create_post", {})`, so you need to understand that if you only want to operate on `user_id=1`, you need to not just accept `{user_id: 1, ...data}`. I dont think its inherently any more insecure than another method, you just have to recognize that clients can create malicious requests to `handle_event(my_event, params, socket)`, just like you might to `my_action(params, conn)`. It's also pretty painless, normal, to just crash on bad data, it will only effect that one naughty lv process. You could also send "control" signals to the phoenix liveview process via the same socket but I dont think that actually as much surface outside of heartbeats and closing the socket.

▲

kitd 5 hours ago | parent | prev [-]

Why? It's the client that initiates the connection.