I've yet to see a Web UI toolkit/framework that works on all of the desktop (Windows, *Linux* and OSX) and Android and iOS. If they manage to pull this off then bravo to them.
Have you seen Flutter?
Tauri Mobile Alpha Release
61–70 of 82 posts
Re: Tauri Mobile Alpha Release
#62Earlier quoted context omitted.
which is still very limited when you need low-level/native access on the platforms, mobile phones especially iphones are very much a locked-in device as much as they can get away with it, android is better though.
If you need native access to a platform, write a native application.
People won't for precisely the same reason Electron became so popular: managing multiple platforms is tiresome. Write once, run everywhere is still the dream.
Re: Tauri Mobile Alpha Release
#63Earlier quoted context omitted.
> it doesn't support AppStore distribution Ironically, having a team specialize on mobile is a great way to catch this kind of problem.
Yes and no, publishing to the Mac AppStore is a slightly different beast. https://github.com/tauri-apps/tauri/issues/4415 TBF I wouldn't bother with the Mac AppStore if there was a simple way of distributing paid versions of the desktop app without much coding involved.
You could check out the combination of Conveyor and Stripe:
Conveyor solves out-of-store distribution and update (albeit, it's not been tested with Tauri specifically yet). You can then have the app check for a license on startup. Stripe integration isn't a lot of coding and the financial overheads are lower than with the app store.
Re: Tauri Mobile Alpha Release
#64I’ve enjoyed working with Tauri a lot, and I’m excited to check out the mobile release. I’ve been using it for about a year now, paired with Svelte, to build a video editor [0] and it’s been really nice speed-wise. I haven’t felt like Tauri is the bottleneck in probably 99% of cases (usually it ends up being my own code!). One area they could improve, and I think they’re working on for 2.0, is the IPC mechanism betwe…
What I’ve been missing in tauri is being able to manipulate the window title bar similar to firefox or vscode (electron actually allows this). Anyway, regarding your IPC bottleneck: I found it faster to spawn a local websocket server in rust and let my vue app connect to it. It’s really ugly and I hate myself for working like this, but albeit the tcp overhead it is actually faster for transferring bigger amounts of d…
Ah yeah, I miss the title bar access too. I had a “# days remaining” button there in the first version of the app when it was native to Mac and went with something less slick this time. The nice thing about Tauri is the native access if you need it, and I think this is probably possible because you can get a handle to the native window, and call native Mac APIs to e.g. access the title bar view and add subviews to it. (of course the downside is having to adapt that code to every platform)
My workaround for the IPC stuff was to just avoid sending binary data at all. I originally wanted to send video frames but it was pretty quickly clear that would not work well at all. So I just send commands, and serialize the timeline back and forth, and do the video on a native layer.
Re: Tauri Mobile Alpha Release
#65I’ve enjoyed working with Tauri a lot, and I’m excited to check out the mobile release. I’ve been using it for about a year now, paired with Svelte, to build a video editor [0] and it’s been really nice speed-wise. I haven’t felt like Tauri is the bottleneck in probably 99% of cases (usually it ends up being my own code!). One area they could improve, and I think they’re working on for 2.0, is the IPC mechanism betwe…
> But I feel a lot better with shipping a lighter app that’s closer to native-size. Out of curiosity: How much time (if any) have you spent addressing differences in OS web renderers? Is not supporting Linux a business or technical decision?
I hit a few bugs on older Safari (like, macOS 10.14) that I had to work around but otherwise it’s been pretty good.
Linux should be technically possible, but it’s a combination of the two that’s made it a lower priority so far. I’m a bit worried about the potential support burden, given how widely systems vary. But it’s on my list of things to look into, at least to try getting it running.
Re: Tauri Mobile Alpha Release
#66> TLS support has been moved behind a Cargo feature until we figure out how to cross compile OpenSSL on Windows.
*war flashbacks*
Re: Tauri Mobile Alpha Release
#67Earlier quoted context omitted.
which ones do they still have now? I know a lot of folks still use third party cordova deps, but i didn't think capacitor did.
For example, i used the http client, but its Android version is just legacy, outdated :(. Not sure if it works with latest Android OS version.
You don't need it, the documentation isn't very good, but I have found that you don't need the http client lib as there is a http plugin that automatically patches the fetch function.
Re: Tauri Mobile Alpha Release
#68I watch F1 and just learned about this lovely project, so it's surprisingly hard to parse "Tauri Mobile Alpha"... those words are in the wrong order!
I came here to say the same. Thought I was misreading it for a second.
Re: Tauri Mobile Alpha Release
#69I'd love to see a GUI engine that is inspired by web technologies but allows you to write your application in any language/shell scripts and have it construct native UIs.
I've been toying with building a GUI-as-a-DB kind of engine where consumers run a server process that listens for commands that tell it to create/update a window & its elements. You would interact with a DOM-like structure that maps to the various native UIs. (there is also a "guidb-lite" for including with your binary)
The general idea is; you issue nosql-like commands to this service to interact with the non-web DOM you create. e.g.
// POST localhost:3344
{
action: 'create-window',
settings: { title: "Hello World" },
content: [{ tag: "Text", value: "Hello World" }]
}
// returns 200 { id: "xxx", "auth": "xxx" }
// POST localhost:3344
{
action: 'update-window',
id: "xxx", auth: "xxx",
exec: { content: {
$findOneAndUpdate: { query: { tag: "Text" }, set: { value: "updated"}}}
}
}
This means your application can be written in whatever language you want. "Frameworks" (like React) would be written on top of this as language-specific implementations - allowing the GUI-DB to focus on only mapping the API to the various native GUI UIs.
I can imagine there would be limitations I am naive to and I'm generally not smart enough to see this through, but it is the change I would like to see in the world.
Re: Tauri Mobile Alpha Release
#70This is a huge reason to go with Tauri over Electron. I don't get why there isn't (or is there) a simple way to package a web app for all platforms. Everyone still makes this weird artificial distinction between Desktop and Mobile despite the technical capabilities and user expectations being close to the same.
https://flutter.dev has very good DX in my opinion for all platforms.
I've been in and out of flutter quite a few times. Only word of caution is, its built by Google, so have a backup plan always ready.