Background
ProxyLight only ships as a macOS menu bar app right now, but most of the code underneath it doesn't actually need macOS. The mapping engine, PAC generation, CA/cert generation, and the SwiftNIO proxy pipeline are plain Swift and Foundation. The macOS-only part is four files — SystemProxyManager, CATrustManager, SelfUpdater, LoginItemManager — plus the SwiftUI app shell itself.
My first thought was to just try building the existing package on Linux, but that doesn't go anywhere while everything sits in one target.
Decisions
- Split
Package.swift into ProxyLightCore (library, portable), the existing macOS app target, and a new proxylight-cli executable target.
- Scope the CLI to proxy + PAC serving + CA cert generation only.
- No automated system-proxy config, no CA auto-trust install, no login-at-boot, no self-update on Linux. The user points their browser at the PAC URL and imports the CA cert by hand.
Acceptance criteria
ProxyLightCore builds and its test suite passes on Linux.
proxylight-cli builds on Linux and runs start/stop, mapping add/list/remove, import/export.
- The macOS app target and its tests are unaffected.
- No system-proxy or trust-store automation on Linux.
Background
ProxyLight only ships as a macOS menu bar app right now, but most of the code underneath it doesn't actually need macOS. The mapping engine, PAC generation, CA/cert generation, and the SwiftNIO proxy pipeline are plain Swift and Foundation. The macOS-only part is four files —
SystemProxyManager,CATrustManager,SelfUpdater,LoginItemManager— plus the SwiftUI app shell itself.My first thought was to just try building the existing package on Linux, but that doesn't go anywhere while everything sits in one target.
Decisions
Package.swiftintoProxyLightCore(library, portable), the existing macOS app target, and a newproxylight-cliexecutable target.Acceptance criteria
ProxyLightCorebuilds and its test suite passes on Linux.proxylight-clibuilds on Linux and runs start/stop, mapping add/list/remove, import/export.