[sergix]

The Tuauri team needs to focus on maturing its primary codebase and documentation before branching out to assign teams to separate projects like this. I've written a few hundred lines of code using Tauri, and I've had to do much more API wrangling and searching the official Discord than I would have liked -- a lot of valuable API details are tucked away in very specific places, especially related to using Tauri's state manager, creating mockup tests, and technical information on the IPC model. In addition, some of those APIs are obtuse and confusing to interpret how to use.

Tauri does a few things very well, and its frontend model is much more lightweight and flexible than Electron's. However, the project has a long way to go before it's used in the mainstream and really needs to continue to make testing, debugging, and other DX details much more accessible and clear to gain an edge in the market.

[Sytten]

I agree with this. We are shipping our app Caido with Tauri and it is missing quite a lot in feature parity with electron. We always lose time to try to bypass limitations or work around bugs. I honestly can't recommend it for production at this moment, even if it is getting better.

Some of the challenges we faced in the last week: no built-in api for single instances (so basically making sure the app is only run once), no support for the task bar menu (right click on the app icon), a fair amount of APIs are platform specific so you need a lot of conditional compilation trickery to make it work, etc.

On top of that you have platform webview issues that are hard to reproduce sometimes since you need the user specific OS version and packages. If you care about uniformity of your UX and speed of development stick with electron.

[andrew_]

> uniformity of your UX and speed of development stick with electron

This is what keeps me from adopting Tauri. I'm following the project with great interest, but I have zero desire to step back in time to wrestle per-platform rendering issues. Big fan of the progression, but it's not quite there yet.

[cpuguy83]

If you care about your user's machines or being able to do anything other than use your app on their machine then please use the platform's tooling and not things like electron.

[rpastuszak]

+10000 I really enjoyed working with Tauri, but had to drop it because after a few days of porting my app to it, I released that it doesn't support AppStore distribution (i.e. creating properly signed .pkg files). This wasn't clear in the docs, and the videos I watched implied the opposite.

The team is doing amazing work and I don't blame them for this, it's perfectly normal for things to slip.

I'm excited about Tauri partially because (in my specific use case) even if I build for Mac only, the UX I can deliver with it will be much better with a hybrid app than SwiftUI [1].

The lesson here is that if you're planning to work with Tauri and Mac, you might want to focus on testing the entire pipeline (design, develop, distribute) first, and then, once you can push to TestFlight, pushing and testing features. Again, YMMV.

[1] Weirdly enough, there's almost no way for me to build a native app that will beat the performance of an optimised web app. Again, my use case is very specific (a niche text editor), but I find it hilarious given how much sh*t web apps get on HN.

[marcosdumay]

> it doesn't support AppStore distribution

Ironically, having a team specialize on mobile is a great way to catch this kind of problem.

[rpastuszak]

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.

[mike_hearn]

You could check out the combination of Conveyor and Stripe:

https://hydraulic.software/

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.

[rpastuszak]

Thanks, but I could probably save time by just using Stripe with the existing Tauri app. Tauri already supports notarised apps, auto-updaters etc... What it doesn't support is generating a properly signed .pkg file.

(this can be done using regular shell script, in my case there is, however, some weird, hard to debug issue with AppStore validation)

The missing bit is making the app paid, which normally should be trivial with the AppStore.

[sergix]

For any specific details that anyone may be curious about, I have a public Notion page with some different documentation issues and the links to their respective sources. [1]

1: https://sergixdev.notion.site/Tauri-Documentation-b695823f0b...