edit_documentBlog Post

Shipping Tauri Apps to the Mac App Store in 2026: What the Guides Don’t Tell You

·


I have shipped three Tauri desktop apps to the Mac App Store this year: Resume Artisan, Saltkey, and Capital Monitor. All three are React front ends over a Rust core, all three went through Apple notarization and App Review, and all three also ship to Windows and Linux through Gumroad. The framework is genuinely good. The distribution story is where the tutorials go quiet, and it is where I lost the most time.

This is the guide I wish I had read before the first submission. It assumes you already know how to build a Tauri app and want to know what actually happens when you try to sell one.

Why Tauri, honestly

The headline pitch is size. Tauri renders your UI in the operating system’s own webview instead of shipping a copy of Chromium, so the binaries are small. The official project says a Tauri app “can be as little as 600KB.” Real apps land higher, but the gap with Electron is still dramatic: one carefully measured 2025 benchmark put a comparable app at roughly 8.6 MB on Tauri versus 244 MB on Electron, with idle memory across several open windows around 172 MB versus 409 MB.

Treat those as one data point, not a law. Because Tauri leans on the platform webview, memory and rendering vary by OS, and there are documented cases where a Tauri app uses more RAM than the Electron equivalent under specific workloads. What you are really buying is a small download, a Rust backend you can trust with real work, and one codebase that now targets Windows, macOS, Linux, iOS, and Android. Tauri 2.0 went stable in October 2024 and the project has been shipping steady point releases since; as of this writing the core crate is at 2.11.5.

The cost you pay is build time. Compiling Rust for a universal macOS binary is not fast, and your continuous integration minutes will notice. That is the trade: slower builds, much smaller and leaner apps.

The Mac App Store is a different pipeline from notarization

This is the first thing that tripped me up, so I will say it plainly: signing an app for direct download and submitting an app to the Mac App Store are two separate pipelines with two separate certificate types.

If you distribute outside the store, you sign with a Developer ID Application certificate and then notarize the app with Apple’s notary service. Notarization is an automated malware scan; Apple says most submissions finish in under fifteen minutes. If you submit to the Mac App Store, you use Apple Distribution and Mac Installer Distribution certificates, and there is no separate notarization step, because App Review’s automated checks cover that ground.

Two practical landmines inside the store pipeline:

  • The App Sandbox is mandatory. A Mac App Store build must declare com.apple.security.app-sandbox in its entitlements, along with your application and team identifiers. If your app quietly relies on writing outside its container, you will find out at review time, not build time.
  • You still upload with altool. Apple deprecated altool for notarization in late 2023, and a lot of blog posts read that as “altool is dead.” It is not dead for App Store uploads, which is why Tauri’s own documentation still uses it. The GUI alternative is Transporter.

The mechanics themselves are well documented: set your bundle category, embed a Mac App Store provisioning profile whose bundle ID matches your Tauri identifier, point your config at an entitlements file, then build a universal binary, wrap it in a signed .pkg, and upload. None of that is the hard part.

Low-light close-up of a laptop screen full of code
The framework is the easy part. Distribution is where the week goes. Photo: Oluwaseun Duncan / Pexels.

The rejection nobody warns you about: minimum functionality

App Review Guideline 4.2 says your app must “include features, content, and UI that elevate it beyond a repackaged website.” For a framework whose entire job is to wrap web UI in a native shell, that sentence should have a warning label on it.

A Tauri app that just loads a website, opens links in the system browser, and does nothing a browser tab could not do is a near-certain rejection. What gets you through is real native integration: local notifications, the system share sheet, native file and photo pickers, genuine offline behavior, native-feeling navigation. Cosmetic touches like a splash screen or dark mode do not count. Before you submit, ask the honest question: if a reviewer opened this next to your website, what could the app do that the site cannot? Have a real answer.

The macOS-specific Guideline 2.4.5 matters too: store apps must be self-contained single bundles that do not install third-party components or write into shared system locations. Tauri’s default bundling is fine here; custom install steps are where people get caught.

The updater plugin does not belong in your store build

Here is a lesson from my own submissions that I did not find in any guide: Mac App Store apps are not allowed to update themselves. The store is the update channel. Tauri’s updater plugin is excellent for your Windows and Linux builds, but it has no place in the Mac App Store target, and leaving it wired in is exactly the kind of thing that turns a one-day submission into a one-week one. Build your store target without it and let Apple handle updates there.

The money math, and why my Windows builds skip the store

Apple’s Developer Program is 99 dollars a year. If you make under one million dollars in proceeds, the App Store Small Business Program cuts Apple’s commission from 30 percent to 15 percent. It is not automatic; you have to enroll, and the reduced rate takes effect the fiscal month after approval. For an indie, enrolling is free money, so do it before your first payout.

Windows is where I made a deliberate choice to step off the official path. A traditional Windows code-signing certificate runs roughly 200 to 500 dollars a year, and the old promise that an Extended Validation certificate instantly clears the SmartScreen warning no longer holds; EV files now build reputation over time like everyone else. Microsoft’s newer Trusted Signing service is far cheaper at about ten dollars a month, but as of 2026 it is limited to the US, Canada, EU, and UK.

So for the Windows and Linux versions of my apps, I sell direct through Gumroad. An unsigned installer shows the “unrecognized app” screen, which a direct-download audience can click through, and I skip the recurring certificate cost entirely. Gumroad also became the merchant of record at the start of 2025, which means it handles global sales tax and VAT for me; its cut is roughly ten percent plus fifty cents per sale. For a solo developer, trading a signing certificate and a tax headache for a platform fee is the right trade until volume says otherwise.

Would I do it again?

Yes, and I have, three times. Tauri gives you a small, fast, cross-platform app with a real systems language underneath it. The Mac App Store is a legitimate channel with a real audience and a fair 15 percent rate once you enroll in the small business program. Just go in knowing that the framework is the easy 80 percent, and the distribution rules are the 20 percent that will actually eat your week: sandbox everything, drop the self-updater from the store build, and have a real answer for the minimum-functionality question before a reviewer asks it for you.

DevWharf builds and ships production desktop, web, and mobile software from the Inland Northwest. If you have a desktop or cross-platform app you want built and actually shipped to the stores, get in touch.


arrow_circle_rightPost Navigation

forumComments

Leave a Reply

Your email address will not be published. Required fields are marked *