這里的深度集成主要是指一些 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 的熱度還有待觀察。
原文地址：The Story About .NET Cross Platform UI Frameworks
擴展閱讀