独立开发者日记：用黑苹果(Hackintosh)和旧电脑开发Mac版Spotmark

大家好，我是CatalystPack Studio。

如果你阅读过上一篇文章，你大概知道我为什么选择Native (C++/Qt) 而不是 Electron 来构建 Spotmark（一个可以直接在屏幕上批注和绘画的工具）。唯一的目的就是为了让应用不卡顿，不吃内存。

这个决定在纸面上听起来很“酷”，但当真正付诸实践时，它带来了一系列像我这样的低预算独立开发者（Indie Hacker）始料未及的困难。

今天，我想分享一点关于这段**Build in Public（公开构建）**的旅程——这是一个没有闪亮的MacBook Pro M3，也没有高端PC主机的真实故事。

C++“跨平台”的承诺与残酷的现实

当使用像Electron这样的Web技术时，操作系统几乎被抽象掉了。你在Windows上编写的界面代码，到了Mac上依然能完美运行。

但Native不同。特别是对于Spotmark这样的Screen Marker——一个需要与操作系统深度交互，以创建一个穿透点击、越过安全层、且全屏透明窗口的应用程序。

C++源码是可以共用的，但Windows (Win32)、Linux (X11/Wayland) 和 macOS (Cocoa) 的系统API却是截然不同的。为了解决这个问题，我绝对需要真机来进行编译和测试。

但问题是……我没钱！

Linux与旧PC上的Wayland难题

为了让Spotmark在Linux上良好运行，我必须在两种环境下测试：旧的X11和新的Wayland。

由于没有专门的Linux电脑，我翻出了放在房间角落里的一台吃灰老旧PC，格式化后装上了Ubuntu。由于这台机器还在用HDD机械硬盘，每次拉取Qt库并运行CMake编译C++源码都需要漫长的等待。但构建缓慢并不是最大的问题。

真正的问题在于Wayland。与X11不同，Wayland有着极其严格的安全协议：默认情况下，它不允许一个应用程序创建一个覆盖在其他所有应用之上的窗口，更是严格限制“穿透点击（click-through）”。

在Windows上，使用Win32 API创建一个透明覆盖层相当简单。但在Linux上，Wayland的机制要求完全不同的方法。测试穿透点击功能并使其覆盖在其他窗口上，需要非常精确的配置才能兼容KDE或GNOME等桌面环境。当一切最终在这台旧PC上设置妥当，Liquid墨迹顺滑地在Ubuntu屏幕上流淌，不再被窗口边框阻挡时，那种感觉真的非常值得。

macOS：迫不得已求助黑苹果（Hackintosh）

与Windows或Linux不同，没有Mac你是无法编译macOS应用（.dmg或.app文件）的。在早期阶段，仅仅为了跨平台测试而去买一台MacBook的成本实在让人望而却步。当时唯一的解决方案是：安装黑苹果（Hackintosh）。

我决定在手头这台Dell Vostro笔记本上“做实验”。折腾过黑苹果的朋友一定懂这种痛：处理OpenCore，配置.plist文件，寻找并修补用于WiFi或核显的Kexts（驱动），这是一个极其耗时的过程。伴随Kernel Panic（内核崩溃）的黑屏重启简直是家常便饭。

经过几天的埋头苦干，这台机器终于能相对稳定地启动进macOS。但macOS又抛出了另一个难题：Accessibility（辅助功能）和 Screen Recording（屏幕录制）权限。苹果会拦截一切与屏幕交互的操作，除非用户在系统设置中明确授予应用程序权限。在一台低配置的黑苹果上测试这种权限流（Permission flow）和Cocoa API的绘制机制有时会有点卡顿，但最终，构建版本还是成功运行了，并且和在Windows上一样流畅。

下一步：从概念验证(PoC)到生产环境

回顾这段时间的过程，与Web框架相比，原生(Native)的跨平台构建确实需要更多配置环境的时间。但从实际性能来看，这种牺牲是完全值得的。

今天，面向Windows的Spotmark v0.4.5 Beta版本正式发布，完全达到了最初的目标：极其轻量，超低延迟。

对于macOS和Linux，首批概念验证（PoC）构建已经在那台Dell Vostro和老PC上成功运行。团队接下来的工作是优化源代码，并将项目整合到自动化的CI/CD流水线中（如GitHub Actions），从而打包出标准的安装文件（Mac的.dmg和Linux的.AppImage）。

如果你是Windows用户，邀请你来体验最新的Beta版： 点击下载 Spotmark v0.4.5 Beta (Windows版) →

如果你使用Mac或Linux，请留下你的邮箱，以便在正式的Native版本完成时第一时间收到通知！

优化的旅程仍在继续。 💻