tiletopia

• Bash ls src-tauri/ && echo "---CARGO---" && cat src-tauri/Cargo.toml && echo "---TAURI CONF---" && cat src-tauri/tauri.conf.j… 142ms 3.1 KB

Good question. Let me look at how platform-specific this app actually is before answering — the WSL dependency is the obvious concern.

• Bash grep -rinE "wsl|wsl.exe|cmd.exe|powershell|windows|\.exe|C:\\\\|backslash" src-tauri/src/ | head -50 55ms 4.3 KB

Yes — it's feasible, but it's not a flip-a-flag thing. The GUI layer is fully cross-platform; the work is all in the backend's platform assumptions. Let me check the two spots that actually matter (keyring + shell-spawn) before quantifying.

• Bash echo "===== lib.rs keyring init (around line 30-55) =====" && sed -n '28,70p' src-tauri/src/lib.rs && echo "===== creds.… 63ms 3.7 KB

• Bash echo "===== pty.rs spawn region 320-380 =====" && sed -n '320,380p' src-tauri/src/pty.rs && echo "===== list_wsl_distros… 49ms 2.5 KB

• Bash echo "===== frontend shell kinds =====" && grep -rinE "powershell|wsl|kind:|SpawnSpec|distro" src/ --include=*.ts --incl… 92ms 2.8 KB

Yes, you can — the architecture is mostly portable. Tauri 2, React, xterm.js, and `portable-pty` all run on macOS, and you even already ship an `icon.icns`. But it's **not** a flip-a-flag job; there are three Windows-hardcoded spots that won't compile or won't make sense on macOS. Here's the honest breakdown.

## What just works
- **GUI / frontend** — Tauri + React + xterm.js: fully cross-platform, zero changes.
- **PTY core** — `portable-pty` spawns native ptys on macOS fine.
- **SSH panes** — `SpawnSpec::Ssh` shells out to `ssh`, which exists on macOS. The one cosmetic snag: error strings and the `build.rs` reference say `ssh.exe`, but the command name `"ssh.exe"` won't resolve on mac — you'd spawn `"ssh"` instead.

## What needs real work

**1. Shell spawn variants (`src-tauri/src/pty.rs`)** — the `SpawnSpec` enum has `Wsl` and `Powershell`, both hardcoded to `wsl.exe` / `powershell.exe`. Neither exists on macOS. You'd add a new variant — call it `Local { cwd }` — that spawns the user's `$SHELL` (falling back to `/bin/zsh`). This is the core of your "uses the built-in terminal" idea. `list_wsl_distros()` (line 511) also shells out to `wsl.exe`; on mac it should just return empty.

**2. Credential storage (`src-tauri/src/lib.rs:36`, `creds.rs`)** — this is the hard compile blocker. The Cargo deps `windows-native-keyring-store` and the Windows Credential Manager backend are Windows-only crates. On macOS you'd swap in `apple-native-keyring-store` (same `keyring-core` 1.x family → macOS Keychain). This needs `#[cfg(target_os = ...)]` gating on both the dependency in `Cargo.toml` and the `Store::new()` call.

**3. Bundle target (`tauri.conf.json`)** — `"targets": ["nsis"]` is Windows-only. Add `"dmg"`/`"app"` (or just `"all"`) so `pnpm tauri build` produces a `.app`/`.dmg`.

**4. Frontend shell selection** — `ipc.ts` and `App.tsx` hardcode the `"wsl" | "powershell" | "ssh"` union and default to WSL. You'd add `"local"` to the union and make the default platform-aware (Tauri exposes `platform()`).

## The real constraint
You can't cross-compile this from your Windows host — the Rust toolchain, code-signing, and `.dmg` bundling all need to run **on a Mac** (or macOS CI like GitHub Actions runners). So "make a macOS build" means: get the code onto a Mac, do the `#[cfg]` work above, and `pnpm tauri build` there.

It's maybe a half-day of focused work — mostly the keyring `#[cfg]` split and the new `Local` spawn path. Nothing architecturally blocks it.

Want me to take a pass at the platform-gating changes (Cargo `#[cfg]` deps, the `Local` spawn variant, conf targets, frontend union)? I can do the edits here; you'd just build on a Mac to verify.

Short answer: **only if that runner is itself a Mac.** The runner being on your Forgejo doesn't change the fundamental constraint — a Tauri macOS build has to run on macOS.

Here's why, concretely:

- **Forgejo/Gitea Actions runners** execute jobs either in a Docker container (Linux) or directly on the host machine. Whatever OS the runner box is, that's the OS you can build for. Your `git.rdx4.com` server is almost certainly Linux — so it builds Linux artifacts, not `.app`/`.dmg`.
- **The Tauri bundle step needs macOS tooling.** Even setting aside the Rust compile, producing a `.app`/`.dmg` (and any code-signing/notarization) relies on Apple's `xcrun`, `codesign`, `hdiutil`, etc. Those only exist on macOS.
- **Cross-compiling from Linux is a dead end in practice.** You *can* get `rustc` to target `aarch64-apple-darwin` from Linux with `osxcross` + a copy of the macOS SDK, but Tauri's bundler won't assemble a real macOS app that way. People who try this abandon it. Don't.
- **Apple's licensing** forbids running macOS in a VM on non-Apple hardware, so you can't just spin up a Mac VM on your Linux box to attach as a runner.

So the decision tree is:

1. **Is the runner physical Mac hardware (or a Mac you control)?** → Yes, register it as a Forgejo runner with the `host` (non-Docker) executor, install Xcode CLT + Rust + node/pnpm, and it can build the `.dmg`. This works great.
2. **Is it Linux/Windows?** → It cannot produce a macOS build. Your realistic options become: a Mac you own (even occasionally, run `pnpm tauri build` by hand), a hosted Mac CI (GitHub Actions `macos-latest` runners are free for public repos / cheap for private; MacStadium, etc.), or a rented Mac mini.

What's the runner running on — is it a Mac, or the Linux box that hosts Forgejo? That determines everything. If it's the Linux host, the most pragmatic path is mirroring this repo to GitHub and using their `macos-latest` runner just for the Mac build, while keeping Forgejo for everything else.

You actually **don't need to own a Mac** — you just need macOS *compute*, and you can rent it by the minute. The "must run on macOS" constraint is real, but it doesn't have to be *your* macOS.

The practical path:

**GitHub Actions `macos-latest` runners.** These are real Apple-Silicon Macs that Microsoft/GitHub host. You push a tag, the runner does `pnpm tauri build`, and you download the `.dmg` from the build artifacts. You never touch a Mac.
- For a **public** repo: free, unlimited.
- For a **private** repo: free tier gives you a monthly minute budget, and macOS minutes bill at a 10× multiplier — but a Tauri build is ~15 min, so you get a handful of builds/month free even private. Cheap beyond that.
- You'd mirror this repo to GitHub (keep Forgejo as origin, add GitHub as a second remote, push tags there). Tauri publishes an official `tauri-action` that handles the whole build-and-release flow.

**Other options if you'd rather not use GitHub:** Codemagic and CircleCI both offer macOS runners; hourly Mac rentals exist (Scaleway Mac minis, MacStadium). But GitHub Actions is by far the least friction for a hobby project.

**One caveat worth knowing now:** an unsigned build works fine — it produces a real `.dmg` — but macOS Gatekeeper will warn users it's from an "unidentified developer" (they right-click → Open to bypass). Making that warning go away needs an Apple Developer account ($99/yr) for signing + notarization. That's optional and orthogonal to *building*; you can ship unsigned first and add signing later.

So: **yes, you can ship a macOS build without owning a Mac.** The realistic plan is two pieces of work:
1. The code changes I outlined (the `Local` shell variant, keyring `#[cfg]` split, bundle targets, frontend union).
2. A GitHub Actions workflow that builds on `macos-latest`.

Want me to do #1 now (the platform-gating edits, here in the repo), and draft the GitHub Actions workflow for #2? You'd just need to create the GitHub mirror and push — no Mac required at any point.