為什麼蘋果不採用託管語言？

01-06

技術不足寫不出虛擬機嗎？

世界並不是離開了微軟的Windows就沒有其它產品了。託管代碼微軟的東西，就技術來說，雖然加入了一些安全因素等的新概念和技術，但是其實就是在解釋程序的思路上走得遠了點（肯定無數微軟技術人員不同意，說出他們之間的諸多本質不同，當然了bash解釋和python的代碼實現也不同，so what），然後固守在Windows系統中而已。微軟自己的ARM平台上不是也開發了另一個Windows RT系統，有了託管後，還是for RT的運行於RT，for Intel的在Intel上，彼此不能混用，然而面臨的市場的失敗後，自己也無情地拋棄了ARM，又回到了Intel的懷抱，可是Phone 10和Surface依然是要死不活苦撐賠本賺吆喝而已。

臨時插一句，OS X的操作系統核心Darwin（Stark Shaw的提醒，OSX中的GUI部分不開源）是開源的，大家可以隨便下載，只不過Apple不會公布最新版本的代碼，比如說這裡：Apple - Open Source，還有這裡：Open Source - Releases。最新開放的代碼是版本10.11.2，目前最新的發行版本是10.11.3；不僅操作系統核心開源，Apple還把部分OSX的GUI所依賴的IO驅動和一些伺服器核心代碼以及開發工具做了開源；不僅如此，它還支持著數量眾多的開源項目，比如CUPS和WebKit；當然Darwin系統本身也是借用了好多其它的開源項目的。蘋果系統的未開放的地方時它的蘋果機的固件(EFI)代碼。可能微軟還沒有開放它的Windows 7代碼，更別提Windows 8/8.1了吧。

其實，真的沒有必要一家推出個新技術，別人就都要跟隨，不跟著就認為是異類。不僅沒必要，而且也不應該，更多的技術的出現不是更有利於技術的發展嗎？特別是對於也就任何巨無霸的無底線追捧和馬首是瞻，是扼殺自我創造性的絞索，更是沒有自信的自卑。

難道說別人都改吃茶葉蛋了，你就不能吃西紅柿炒飯了。說了半天題主提的問題就是一個假命題而已。

蘋果軟硬體一體，系統封閉，開發的東西基本上只在自家平台跑，並不需要託管語言。

託管語言是為了犧牲硬體性能來換取兼容性，蘋果沒有這個需求。

當然，蘋果也提供對很多已有的託管語言的支持，以便讓蘋果平台能夠兼容別人開發的應用。

這是典型的程序員思維. 蘋果在語言方面採用什麼不採用什麼, 技術上面一定是是次要的, 真正重要的是市場需求考慮. 現有的Cocoa體系可以做得很好, 幹嘛非得要弄一套新東西出來?

Google的Android為何採用虛擬機, 也沒有特定的技術意義, 甚至跟Google是否技術牛並無明顯關係, 只是恰好收購的Android這貨正好是如此設計的.

要論真正技術主導的, 微軟應該算是, 每次提一個新概念, 就要換一套體系, 技術力量是表現足了, 但我們開發者們跟不上他老人家的步伐啊, 它的市場也被弄得非常失敗.

----------------------------

下面有人說"蘋果技術不足, 甚至是有很多不可逾越的鴻溝", 雖然我很想說此人自大, 但既然是主觀認知, 我不做具體評價. 只是下面說mac是x86, iphone又是arm架構, 所以蘋果比任何公司更需要託管語言, 這個說法是典型的將硬體架構和軟體架構混為一談的表現. 做開發的, 一般關注最多的是軟體層, 不管是x86還是arm, 開發人員關注的只是api層居多.

如果有一天, 市場上出現了mac程序要運行在iphone上的需求, 那麼託管層的出現自然會有, 但是, 前提條件一定是市場需求出現, 然後才去做. 而不是蘋果有了這個技術能力, 就要去做.

再說回微軟, 微軟也搞過arm,mips之類的架構, 當年搞.net的時候, 其中一個理由, 就是.net要適應多平台, 比如windows http://ce.net , 按照此人的觀點, 理應是微軟有託管語言需求啊. 當然, 按照我的看法, 這個需求根本就不是市場需求, 而是微軟憑空想像的需求, 從技術出發, 剝離市場的決定. 直到今天, 微軟仍然陷在這個泥潭中, 比如win10 mobile, 還是在想像著一個程序能夠同時運行於pc和mobile上, 這個想法確實很酷, 但是, 真有用戶有那麼強烈的需求要將一個pc應用運行在mobile上嗎? 至於對開發人員的便利, 坦白講, 你的api長得一樣, 就足夠了啊.

swift語言的開發難度比java高

從技術角度來考慮的話，託管大致有兩個原因。

一，託管方便跨平台部署，可 Apple 並沒有這個需求。Apple 作為一家設計主導的娛樂公司（大霧），短時間內是不可能切換到共用 iOS 和 OS X 的界面的。換句話說，這兩邊連源代碼水平的共享都做不到，何談什麼二進位共享？此外，實際上 Apple 在這方面也是做了一些努力的，比如說 Swift 可以檢查 API availability:

if #available(iOS 9, OSX 10.10, *) { // Use iOS 9 APIs on iOS, and use OS X v10.10 APIs on OS X } else { // Fall back to earlier iOS and OS X APIs }

此外，跨平台部署這個需求本身有多強烈呢？在這個空間換時間的地方，人們完全可以給多個平台輸出專門的代碼，然後打包起來。其實 Apple 的 iOS app 本身就在這麼干，還專門提供了 App Thinning 減小代碼體積。相比之下，每次啟動的時候先解釋執行再加熱 JIT 可能太不環保了。Google 最近好像也開始整 Android 代碼安裝期編譯了。

二，託管代碼配合 JIT 理論上性能可能會高於 AOT，因為 JIT 可以實時收集執行數據，根據不同用戶場景為關鍵路徑做優化。不過理想很美好，但現實中好像沒有什麼大進展——至少對於手機、個人電腦這樣的場景，據我所知 Apple、Google、Microsoft 都沒有這麼干。JavaScript 確實這麼幹了，但是人家弱類型不好優化——其實也不一定——再加上標準限制，之前一直沒有統一的二進位編碼標準。

說 Apple 沒有這個技術的並沒有什麼道理，LLVM 最初的設計就是考慮到軟體整個生命周期的優化，不過看起來好像坑了，這方面我不是很熟悉。如果我沒記錯的話，老舊 Mac 里的 OpenCL API 就是用類似託管代碼的形式解釋執行一部分老顯卡所不支持的特性的，用的是 LLVM 子項目 compile-rt。更何況 Apple 本來就不是一家自研為主的公司。他們連生產線都外包，技術研發怎麼就不能外包？有技術買就是咯，和自己養著又有什麼區別？P. A. Semi 的故事大家都忘記了嗎？

最後，其實 Swift 之所以搞成這個樣子，也沒什麼複雜的原因，慣性而已。如果是微軟內部的人開發一個新的語言，他們自然不介意用 .NET 工具鏈節約時間，編譯成 AST、輸出二進位代碼就好了。而 Apple 動手——尤其是 Chris Lattner 本人動手——怎麼會不用 LLVM 呢？

免責聲明：作為學政治科學、不會寫代碼的社科生，以上所有信息都是我夢遊時打出來的，不保證準確性。

我同意 @假牙妹妹的說法。

我再補充一下，蘋果App在兼容性上面沒有遇到問題么？也有的，譬如，平板和手機，版本升級後，強迫新的App使用新的API，強迫64位。老用戶就被迫升級新的系統，老硬體升不了新系統被迫淘汰。這不過果粉往往很寬容而已。所以

api長得一樣, 就足夠了啊

真的不夠。在產品的升級線上，你必須在使用舊API，還是設計新API上做出選擇。那能不能保留舊API，同時開發新API呢？回答：那樣除了造成內核臃腫之外，還會造成混亂。

微軟在Windows上推出.net，就是為了兼容和淘汰舊品之間達到更好的平衡。一方面，微軟在Win32 API的上面，可以說已經做到了變態的兼容。然而這種兼容是以落後的開發效率為代價的。微軟開始推出.net 時，也許有脫離C++的想法，但沒有成功（一方面是性能的需求，另一方面是C++的用戶真的是太多了）。不過，它在「逐漸淘汰舊品的同時提供最新技術」，這方面做得很好——同一系統可以同時安裝多個版本的.net ，開發人員可以根據自己軟體的受眾來自由選擇自己使用哪套.net 。

當然，有人會說：微軟在手機上又怎麼解釋呢？ —— 這個跟蘋果其實還真不一樣，首先，它之所以全套更換，是因為它的前產品失敗了。

// 另外，新產品還是失敗的。

除此以外，託管語言不一定就是低運行效率，普通應用是足夠的，就不多說了。而且展望未來，差距只會越來越小，為了提高一點點性能而枯腸白首，不是很值得鼓勵的事，往往是因為不得已。

尤其是現在.net naive —— sorry —— native 出來了，我對未來「科技進步，人力得到釋放」是信心滿滿的。

至於蘋果有沒有這實力，道理是這樣說：有錢就有實力。只是公司自身有取捨，蘋果明顯就是通過封閉、嚴格控制介面等等方式迴避了軟體的複雜性帶來的風險。從這一點看，它是自身選擇了更少的軟體技術依賴。所以用天平稱一下，說技術不足也無多大問題。

OS X上Java、C#等託管語言都可以運行。iOS上不採用是軟硬體控制，原生語言性能高。

Android採用Java是為了爭取大量現存Java程序員和Java庫

都是自家的東西，而且互相兼容性太高，不需要託管這種慢貨。

技術不足？還是省省吧。

講道理蘋果一個時尚公司你指望他們程序員水平有多高？

.NET 回 Native 了, 半生在世說的好, 自家平台那都不能混用, 還整過什麼 C++CLR, C++/CX 之類的東西. 真會瞎鬧.

Java 也有很強的 AOT 需求.當然伺服器端不是很迫切

比較新的高性能語言, Rust Go Swift ... 都不會考慮託管.

託管完全就是走了 N 年彎路, 軟爹都認慫了你還不醒.