Xamarin.Mac升级Ventura后libXYZ失效，该换库/转Forms还是MAUI？

我已开展一个项目数年。项目启动时，Xamarin.Forms尚不具备我所需的全部功能，因此我选择了Xamarin.iOS和Xamarin.Mac，所有业务逻辑代码均为共享的C#代码。项目耗时远超预期，但目前正处于与外部测试人员进行最终验收测试的阶段——换句话说，我即将完成项目！

然而我遇到了一个难题：我重度依赖的一个库（暂称libXYZ）已停止支持Xamarin.Mac（但仍支持.NET Core）。起初这并未造成影响，一切运行正常。我曾与该库的开发人员沟通，他们表示该库应能继续正常工作。

但在系统升级至Ventura后，情况急转直下。由于某些灾难性的变化，Mac端项目因libXYZ出现异常故障而无法运行。我已与该库的一名开发人员协作排查，但由于Xamarin.Mac已不再受支持，他也无能为力。不过Xamarin.iOS仍可正常运行。

目前我的项目拥有大量基于Xamarin.Mac和Xamarin.iOS的UI代码，以及大量C#编写的业务逻辑代码。

我目前有以下几种选择：

• 替换libXYZ：这是一项庞大的工作。我已调研了一些替代方案，其中一个似乎能满足我的需求（但需先进行大量测试与重构）。此方案意味着我需继续使用Xamarin。
• 迁移至Xamarin.Forms：需完全重写UI。我的核心UI需求是一款优秀的富文本编辑器（类似{NS,UI}TextView），而SyncFusion提供了一款适用于Forms的不错的跨平台富文本编辑器。
• 迁移至MAUI：需完全重写UI，但能更快实现对Windows/Android平台的支持。遗憾的是，MAUI目前缺乏富文本编辑功能，且SyncFusion尚未公布其MAUI版富文本组件的推出时间。

我的顾虑在于，微软正在大力推广MAUI，Xamarin.Forms即将终止支持（EoL），若迁移至Forms，不如直接转向MAUI。但MAUI目前尚不成熟，基于XAML构建大型复杂UI难度较高，且缺少富文本编辑功能。

此外，微软已宣布Xamarin将于明年终止支持（EoL），因此继续使用Xamarin在短期内也存在问题。

我已为此决策纠结数周，希望能得到各位的建议与意见。是否还有我未考虑到的方案？

短期救急+长期迁移的组合策略 #

• 短期优先解决Mac端运行问题：

  • 尝试将Mac端项目迁移到Mac Catalyst（基于.NET 6+）：由于libXYZ支持.NET Core，Mac Catalyst完全兼容.NET生态，且和Xamarin.Mac的API高度重合，大部分UI代码只需少量调整即可复用，业务逻辑可以直接迁移。这样既能解决Ventura下的故障，又能脱离Xamarin.Mac的EoL限制。
  • 若Mac Catalyst迁移有阻碍，可临时将libXYZ封装为.NET Core控制台服务，通过本地进程通信（如gRPC、Socket）让Xamarin.Mac项目调用，改动量极小，能快速恢复Mac端运行，先完成验收测试。
  • 极端应急方案：临时降级Mac系统到非Ventura版本，先通过验收，为后续迁移争取时间，但这只是权宜之计。

• 长期分阶段过渡到.NET生态：

  • 先稳定Mac端后，逐步将iOS端迁移到.NET for iOS，业务逻辑完全复用，UI代码可分批重构，避免一次性重写的风险。
  • 针对MAUI的富文本空白：可以自行封装原生控件，通过MAUI的Handler机制在iOS端包装UITextView、Mac端包装NSTextView，实现跨平台富文本编辑，无需依赖第三方组件。

现有选项的利弊权衡 #

• 替换libXYZ：不优先考虑，项目已到验收阶段，替换核心库会带来大量测试和重构工作，风险高、周期长，容易延误交付。
• 迁移至Xamarin.Forms：不推荐，Xamarin.Forms即将EoL，投入大量精力重写UI后很快就要再次迁移到MAUI，造成重复劳动。
• 迁移至MAUI：适合作为长期目标，但不适合当前全面迁移。建议先适配业务逻辑到MAUI兼容的.NET标准，再逐步重构UI，或先通过Mac Catalyst过渡，待MAUI成熟、富文本组件到位后再完成迁移。

补充方案 #

• 若libXYZ是开源项目，可自行修改代码添加Xamarin.Mac兼容；若闭源，尝试寻找第三方兼容补丁，或通过反向工程封装调用逻辑（技术门槛较高，需评估成本）。

内容的提问来源于stack exchange，提问作者Paul