Windows support — v4's Go architecture makes this feasible

[chaoz23]

Follows up on #266, which was closed when Finicky was pure Swift and a port wasn't realistic. The v4 rewrite changes that equation.

The pitch

I'd like to contribute Windows support for Finicky. There's nothing like it on Windows — no rule-based browser router, period. Users are stuck manually switching default browsers or clicking through browser picker dialogs.

~87% of the v4 codebase is already cross-platform (Go + Svelte + TypeScript). Only the Objective-C platform layer (~930 lines across 8 files) needs Windows equivalents.

I've done a detailed analysis of every macOS API call in the codebase and mapped each to its Windows equivalent:

Component	macOS (current)	Windows equivalent	Effort
App event loop	NSApplication	getlantern/systray Go lib	Low
URL receiving	Apple Events (kAEGetURL)	Registry protocol handler + named pipe IPC	Medium
System tray	NSStatusItem	getlantern/systray	Low
Default browser get/set	NSWorkspace Launch Services	Registry UrlAssociations + ms-settings:defaultapps	Low
Browser discovery	NSWorkspace.URLsForApplicationsToOpenURL	Registry StartMenuInternet scan	Low
Browser launch	exec.Command("open", ...)	Direct .exe invocation	Low
Config window	WKWebView + NSWindow	webview/webview Go lib (wraps WebView2)	Low
JS↔native bridge	WKScriptMessageHandler	webview.Bind()	Low
Modifier keys	NSEvent.modifierFlags	GetAsyncKeyState()	Low
Battery/power	IOPowerSources	GetSystemPowerStatus()	Low
Running app check	NSWorkspace.runningApplications	CreateToolhelp32Snapshot	Low
Window title	Accessibility API	GetWindowText()	Low
Home/cache dirs	NSHomeDirectory()	Go stdlib os.UserHomeDir()	None
Single instance	NSRunningApplication terminate	Named mutex (CreateMutex)	Low

14 of 18 API mappings are drop-in replacements. Only URL receiving needs architectural work — on macOS the OS pushes URLs to a running app via Apple Events; on Windows the OS launches a new process with the URL as argv[1], so the port needs a named pipe to forward URLs to the running instance. This is a well-established pattern (VS Code, Slack, and Spotify all do it).

Proposed approach

Zero changes to existing macOS code. The approach uses Go build tags:

• Rename 5 existing files with _darwin.go suffix (adds //go:build darwin constraint)
• Split 3 files that mix portable logic with cgo calls (e.g., launcher.go — profile parsing is portable, the open command is not)
• Create 7 new _windows.go files (~620 lines total)
• Extend browsers.json with Windows exe names and AppData config paths
• Add 3 Go dependencies: webview/webview, getlantern/systray, golang.org/x/sys/windows

The Svelte UI, TypeScript config engine, Go rule engine, resolver, shorturl expander, config watcher, and JS VM — all compile and run as-is on Windows with zero modifications. The .finicky.js config format stays identical, so users can share configs across platforms.

Files untouched: config/, logger/, resolver/, rules/, shorturl/, version/, assets/, packages/ (the entire Svelte UI).

The one architectural difference

On macOS:

User clicks link → OS routes to running Finicky via Apple Events → HandleURL()

On Windows:

User clicks link → OS launches finicky.exe with URL as argv[1]
  → Check for existing instance via named mutex
    → If exists: send URL over named pipe to running instance, exit
    → If not: become main instance, start pipe server, process URL

What I'm asking

Would you accept a PR that adds Windows support via this approach? Specifically:

1. Are you open to the build-tag file structure (existing macOS code stays untouched, Windows files live alongside)?
2. Any concerns about the new dependencies (webview/webview, getlantern/systray, golang.org/x/sys/windows)?
3. Would you want Windows CI (GitHub Actions) added to the repo, or should that live in a fork?

If you'd prefer this as a community fork rather than upstream, that's completely fine — I'd maintain config format compatibility either way. Just want to check before doing the work.

Happy to share the full file-by-file analysis if helpful.

[chaoz23]

Quick update — I went ahead and built out a working Windows port based on the v4 architecture, since most of the codebase (Go/Svelte/TypeScript) is already cross-platform. Happy to share details or open it as a draft PR if that's useful.

What's implemented:

• Platform-specific layer via Go build tags (_windows.go files), mirroring the existing _darwin split
• URL handling: named mutex for single-instance + local socket IPC to forward URLs to the running instance (replaces Apple Events)
• WebView2-based UI via jchv/go-webview2 (pure Go, no cgo — keeps cross-compilation simple)
• Browser detection/launching via the Windows registry + known install paths, with config_dir_windows added to browsers.json for profile resolution (Chromium Local State, Firefox profiles.ini)
• Default-browser registration via Inno Setup installer + registry protocol handlers
• CI workflow for Windows builds, plus a winget manifest draft

Cross-compiles cleanly from macOS (GOOS=windows CGO_ENABLED=0), tests pass on both platforms, no changes to existing macOS behavior.

No pressure on timeline — just didn't want this to sit invisible. If you'd rather review a PR than a wall of text, say the word and I'll open one. If you're not interested in merging Windows support upstream, totally understand — happy to maintain it as a separate fork instead, just wanted to check with you first given it touches browsers.json and a few shared files.

[johnste]

Very interesting!

The reason Finicky has this particular architecture (Go / Goja / Webviews) was to potentially support other platforms, so this very much looks great, but I'm concerned about the added effort supporting Windows would be. I'll have to think about this for a while. If you want to completely fork I understand, and I don't want to be a blocker.

[chaoz23]

Thanks — that genuinely means a lot, and the maintenance concern is completely fair.

I've opened a draft PR (#542) so the surface area is concrete rather than hypothetical — zero obligation to merge.

A few things should keep the Windows burden off you:

• Fully isolated behind build tags. Every Windows file is //go:build windows; your macOS build is unaffected (verified — no regression). Nothing in the shared Go/Svelte/TS changes macOS behavior.
• I'll own the Windows side — triage and fix Windows issues, keep the platform layer current as the core evolves, and handle the Windows release artifacts (installer, winget).
• Separate, non-blocking CI — the Windows workflow builds and tests independently; it won't gate your macOS releases.

I've done two QC passes on the port (including a Windows-specific thread-affinity audit that caught a WebView2 message-loop bug only visible on real hardware) and documented the platform layer (WINDOWS_PORT_QC.md) so it isn't a black box.

Fully honest on status: it cross-compiles and unit tests pass, but I haven't smoke-tested on physical Windows hardware yet — that's the next step, hence the draft.

And if you land on preferring I fork, genuinely no hard feelings — I'll keep config compatibility so rules port over 1:1. Really appreciate the architecture making this possible in the first place.