现在用 C# 来开发跨平台应用已经有很成熟的方案，即共用非界面代码，而每个操作系统搭配特定的用户界面代码。这个方案的好处是可以直接使用操作系统原生的控件和第三方控件，还能够和操作系统深度集成。
这里的深度集成主要是指一些 Windows 专有的系统特性：
Windows 托盘
Windows 跳转列表
Windows 系统主题
也包括一些移动平台的特性，例如 iOS 的原生滑动。
由于操作系统上其他程序一般都使用原生控件，于是只有当你的程序采用同样技术时，它才能很好地保持一致。这是一个大家一般遵守的界面开发约定。苹果公司有详细的界面设计准则，供开发者参考。
游戏程序一般全屏，也不需要遵守这个约定。其他程序，例如 RealPlayer、QQ，也是违背这种约定。个人观点是，尽量不要搞特殊化。
因此如果你决定采用这个方案，那么在不同的操作系统上你需要学习不同的界面框架：
Windows：Windows Forms *
macOS：Xamarin.Mac（封装 Cocoa） **
Linux：GTK#（封装 GTK+）***
iOS：Xamarin.iOS（封装 CocoaTouch）
Android：Xamarin.Android（封装 Android UI)
值得注意的是：
* Windows 平台正在经历整体界面设计的变化，未来标准的界面框架应该是 UWP。WPF 虽然也是微软官方支持的技术，但是和 WinForms 相比，它依然是自己绘制，算不上原生界面框架。
** MonoMac 因为各种原因已经废弃 参见。
*** QtSharp 等框架都不太成熟。
市场上很多成功的项目都是这个方案的受益者。下面举几个例子：
国家仪器的 LabView 官方网站 在 iOS 平台使用 Xamarin.iOS 移动版地址，在 Windows 平台使用 Windows Forms（这个不是特别确定）。
Plastic SCM 官方网站 在 Linux 平台使用 GTK#，在macOS 使用 Xamarin.Mac，而在 Windows 上使用 Windows Forms。
iCircuit 官方网站 在 macOS 使用 Xamarin.Mac，在 iOS 使用 Xamarin.iOS，在 Android 使用 Xamarin.Android，在 Windows 和 Windows Phone 上使用微软的技术。
不过总有程序员希望能够使用跨平台界面框架，来简化自己的工作。所以这篇文章也介绍一些业已存在的跨平台界面框架，以供参考。它们虽然各不相同，但是大体都使用了下面三种设计思想中的一个：
控件完全自己绘制，在不同操作系统上模拟系统控件的效果。
在某个操作系统上是原生框架，在其他操作系统上通过模拟实现显示。
设计时抽象，运行时映射到原生控件。
Unity/MonoGame
设计思想：完全自己绘制（不过没有什么标准控件概念）
操作系统：桌面和移动设备（还包括游戏终端等）
显示效果：和操作系统没关系
三方控件：谈不上
这两个都是游戏引擎。非要用它们来设计跨平台应用技术上是可行的，但是因为没有操作系统控件之类的东西，完全需要自己绘制，所以开发非游戏应用，难度还是有的。至于和操作系统深度集成，就更加麻烦。
GTK#
设计思想：在 Linux 上是原生框架，在其他操作系统上也能模拟运行。
操作系统：桌面
显示效果：Linux 上深度集成
三方控件：有一些，但没有非常活跃的提供商
GTK 本来就是一个针对桌面程序开发的跨平台界面框架，所以 GTK# 封装之后也是很好用的。然而，它在非 Linux 操作系统上的显示效果是很差的（比如 Windows 上和系统主题很不搭）。
MonoDevelop 是采用 GTK# 的 IDE。当微软/Xamarin 将它改造为 Visual Studio for Mac 时，很多界面部分就已经换成了系统原生的 Xamarin.Mac 了。
Windows Forms
设计思想：在 Windows 上是原生框架，在其他操作系统上也能模拟运行。
操作系统：桌面
显示效果：Windows 上深度集成
这是绝大部分 C# 程序员入门时学习的界面框架，能够快速集成 Windows 各种控件。虽然也支持 Windows CE 移动平台，但是基本没什么用。Mono 从2.0版本开始将它迁移到 Linux 等操作系统。Plastic SCM 最初也是使用 Mono Windows Forms 将自己的 Windows 客户端迁移到其他操作系统。但是 Mono 的实现在很多细节上并不完美，还需要很大精力去改进。Plastic SCM 后期就放弃了跨平台 Windows Forms 这条路。
Windows Forms 在 Windows 平台拥有大量第三方控件，而这些控件基本都不支持 Linux 等操作系统。尽管最近微软开始将 System.Drawing 变成一个跨平台技术，也使得官方的 Windows Forms 有可能成为一个跨平台界面方案，但是在非 Windows 平台的显示效果如何抑或是三方市场会不会跟随都还未知。
最为重要的是 Windows Forms 本来就是为桌面设计，它没法很好的支持移动平台。早在 MonoTouch 最初开发阶段，Mono 团队就有想过将 Windows Forms 变成 iOS 平台的界面框架 相关文章。当然，最后他们很明智地放弃了这个想法，而是采用了封装 Cocoa Touch 的原生方案。
WPF/Avalonia/UWP
设计思想：完全自己绘制。
操作系统：桌面（UWP 支持 Windows 移动版，Avalonia 有移动支持）
显示效果：Windows 上深度集成
三方控件：Windows 平台很多
WPF 和 UWP 都是微软官方的技术，而 Avalonia 官方网站尝试将类似的设计变成一个跨平台的技术。
Delphi 有一个非常像 WPF 的界面框架 FireMonkey，已经完全跨平台（桌面和移动设备），所以 WPF 相关技术想跨平台技术上是完全可行的，但是挑战也是很多的。
虽然微软想了很多办法来改进 WPF 和系统的集成（包括多套主题），但是它始终不能像 Windows Forms 那样原生显示。当然从 Windows 10 开始，微软干脆用 UWP 来开发系统自带的程序，这样 UWP 最后还是会成为原生框架的。
Xamarin.Forms
设计思想：原生控件映射。
操作系统：移动平台（开始尝试桌面支持）
显示效果：总是和原生系统深度集成
三方控件：快速发展中
Xamarin 开发这个技术，最开始是为了跨平台移动应用，但是最近它已经开始走向桌面场景，比如 macOS（WPF 和 GTK# 的集成也在开发中）。
和完全自己绘制技术不同的是，Xamarin.Forms 程序在设计时使用的是抽象控件。设计时的按钮、列表等控件，到运行时会映射到操作系统原生的按钮、列表等控件上。所以从显示效果来看，这是最好的一项技术。
更为重要的是，Xamarin.Forms 新版本已经支持直接嵌入原生控件，也支持原生程序嵌入 Xamarin.Forms 界面，为开发者带来更多的灵活性。
但是这个技术暂时也是有局限的，就是它的控件都还是为移动应用设计。假如你的目标是设计一个 Office 或者 Visual Studio 那样的标准桌面应用，那么就会遇到困难。好在也不是所有场景我们都需要那么复杂的界面。
现在已经有很多第三方为 Xamarin.Forms 提供控件：
越来越多三方的加入也使得这个技术更加活跃。
xwt/Eto.Forms
设计思想：原生控件映射。
操作系统：桌面（开始尝试移动支持）
显示效果：总是和原生系统深度集成
三方控件：暂时不多
这两个技术都和 Xamarin.Forms 相似，但是它们都是从桌面平台开始的。
xwt 官方网站 是 Mono 项目的一部分。我个人认为它启发了 Xamarin.Forms 的设计。Eto.Forms 官方网站 相对比较新，而且开始进入移动平台。
这两个框架会不会最后到达 Xamarin.Forms 的热度还有待观察。
http://www.cnblogs.com/leolion/p/7144896.html
延伸阅读
- .NET C#到Java没那么难，MVC篇 2017-07-26 16:35:54.353
- 【.net 深呼吸】在运行阶段修改应用配置文件 2017-07-26 11:58:04.92
- .NET C#到Java没那么难，DB篇 2017-07-25 16:10:33.153
- 编写一个可配置的网页信息提取组件 （二）—— 优雅的.net core 配置系统 2017-07-25 14:33:29.213
- 【.net 深呼吸】自己动手来写应用程序设置类 2017-07-25 10:01:22.473
- .NET Core 事件总线,分布式事务解决方案：CAP 2017-07-21 10:10:49.537
- 利用Advanced Installer将asp.netMVC连同IIS服务和mysql数据库一块打包成exe安装包 2017-07-20 16:09:21.323
- .NET插件技术-应用程序热升级 2017-07-19 16:07:37.427
- 十年过去了，各位 .net 兄弟还好吗 2017-07-19 14:28:20.837
- # .NET切面编程——PostSharp 2017-07-19 09:48:12.47
.NET C#到Java没那么难，MVC篇