蘋果公司似乎在Swift上還有更大的目標唆铐。它的編譯器性能和開發(fā)語言都被優(yōu)化了着茸，蘋果公司在Swift的文檔中暗示Swift被設計成小能（顯示）“hello,world”族扰，大能（完成）整個操作系統匿情。蘋果公司還沒把這門語言的目標說全扭倾，Xcode6诅需，Playgrounds和Swift的推出就一起揭露蘋果的意圖：更簡單的應用開發(fā)漾唉，更易用的開發(fā)工具鏈。

這是從現在起使用Swift工作诱担，并走在比賽前列的10個原因毡证。

1. Swift 容易閱讀

如你所能預計到的一門基于 C 構建的語言，Objective-C 身上所有的毒疣子都有蔫仙。為了將關鍵詞和類型同C的類型作區(qū)分料睛，Objective-C 使用@符號引入了新的關鍵詞。因為 Swift 不是基于C構建的摇邦，它同意了所有的關鍵詞恤煞，并將 Objective-C 類型和對象相關的關鍵詞前面大量的@符號移除了.

Swift 丟棄了遺留下來的約定。因而你不再需要行尾的分號施籍，以及 if/else 語句中圍繞條件表達式的括弧居扒。另外一個大變化就是方法的調用不再互相嵌套成中括號的深坑 -- 再見吧，[[[ ]]]丑慎。Swift 中的方法和函數的調用使用行業(yè)內標準的在一對括弧內使用逗號分隔的參數列表喜喂。這樣做的結果就是一種帶有簡化了句法和語法的更加干凈有表現力的語言。

除了其它當代流行的編程語言之外竿裂，Swift 更像是自然的英語了玉吁。這種可讀性是的其很容易能被其它來自 JavaScript，Java腻异，Python进副，C#，以及 C++ 的開發(fā)者納入到他們的工具鏈之中 -- 一點也不像 Objective-C 這只笨笨的黃小鴨悔常。

2. Swift 更易于維護

歷史遺留問題會讓 Objective-C 越來越倒退 -- C 沒有演進的話影斑，這個語言也就跟著無法進行演進给赞。C 需要程序員維護兩套代碼文件，以優(yōu)化構建的時間以及創(chuàng)建可執(zhí)行 app 的效率, 這種需要延續(xù)到了 Objective-C 上矫户。

Swift 丟掉了對著倆文件的要求片迅。Swift1.2 中 Xcode 和 LLVM 編譯器可以自動計算出以來并執(zhí)行增量構建。如此吏垮，將內容清單 (頭文件) 同內容主體（實現文件）相分離障涯。Swift 將 Objective-C 頭文件(.h) 和實現文件 (.m) 合并成了一個代碼文件 (.swift）。

3. Swift 更加安全

Objective-C 有意思的一個方面是指針 -- 特別是 nil (null) 指針 -- 它們被處理的方式. 在Objective中-C, 如果你調用方法的是一個值為 nil (未初始化)的指針變量膳汪，什么事情都會不發(fā)生. 表達式或者一行操作變成了一項空操作（no-operation (no-op)）, 而這就使得其看起來會有不會奔潰的好處, 但其實它已經變成了一個巨大的bug來源. no-op 會導致不可預測的行為, 這是程序員在嘗試找出并修復某種隨機的奔潰，或者要停止反常的行為時所要面對的敵人.

在Swift代碼中的可選類型使得一個nil可選值的可能性變得非常的明確, 這意味它能在你寫下一段糟糕的代碼時會生成一個編譯器錯誤. 這就建立了一種短程反饋的循環(huán)九秀，可以讓程序員帶著目標去寫代碼. 問題在代碼被寫就時就可以被修復, 這大大節(jié)省了你要在修復有關來自 Objective-C 指針邏輯的bug時需要耗費的時間和金錢.

在 Objective-C 的傳統中, 如果某個值返回自一個方法, （使用注釋以及方法的命名約定來）說明指針變量被返回的行為是程序員的責任.在 Swift 中, 可選類型和值類型使得方法定義中值是否存在遗嗽，或者其有可能是可選的（即值可能存在也可能為nil），這些問題都是很明確清楚的.

為了提供對行為的預測鼓蜒，Swift會在nil可選值被使用時觸發(fā)一次運行時崩潰痹换。 崩潰提供的就是一種一致的行為，它能減輕修復bug過程的壓力都弹，因為它會直白地強制讓程序員修復好這個問題. Swift 運行時崩潰的時候會停在nil可選值被使用到的那行代碼處娇豫。這就意味著bug能更早的被修復，并能在Swift代碼中被完全的規(guī)避掉.

4. Swift 的內存管理是統一化的

Swift 以一種 Objective-C 從未有過的方式進行了統一畅厢。對自動引用計數 (ARC) 的支持是在整個過程化的和面向對象的代碼路徑上完成的冯痢。在。Objective-C框杜。中, ARC 在 Cocoa API 和面向對象代碼中獲得支持浦楣；然而它并不支持過程式的 C 語言代碼和像?Core Graphics 這樣的 API。這意味著在使用 Core Graphics API 以及其它 iOS 上的底層 API 時咪辱，內存管控的處理都是程序員的責任振劳。程序員在 Objective-C 上會遇到的大量內存溢出問題在 Swift 上是不可能的。

程序員不應該為他或她創(chuàng)建的數字對象去考慮內存的問題油狂。因為 ARC 在編譯時就處理了所有的內存管理事務, 內存管理所有消耗的腦力現在可以被用來專注于核心的應用邏輯以及新的功能特性历恐。因為 Swift 中的 ARC 在過程式的和面向對象的代碼中都能起作用，它也就不再需要程序員進行心理上的上下文切換了, 即使是他們在編寫要觸及底層API的代碼時也不需要 -- 這在目前版本的 Objective-C 中就是一個實實在在的問題专筷。

自動和高性能的內存管理是一個已經被解決的問題弱贼，而蘋果公司已經證明了這個問題的解決可以提高生產力. 另外一個副作用就是 Objective-C 和 Swift 不會像 Java，Go 或者 C# 那樣遇到垃圾收集器針對沒有被使用的內存運行清理作業(yè)的情況. 這對于那些將會被用于相應圖形和用戶輸入的編程語言而言就是一個非常重要的要素, 特別是在諸如 iPhone仁堪、Apple Watch 以及 iPad 這樣的(如果響應滯后就會讓用戶感知上以為應用是壞的)觸摸屏設備上哮洽。

5. Swift 代碼更少

Swift 減少了重復性語句和字符串操作所需要的代碼量弦聂。在 Objective-C 中, 使用文本字符串將兩塊信息組合起來的操作非常繁瑣氛什。Swift 采用當代編程語言的特性匪凉，比如使用“+”操作符將兩個字符串加到一起，這在 Objective-C 中是沒有贸铜。像這樣支持對字符和字串的組合對于任何要在屏幕上向用戶展示文本的編程語言的基礎設施聂受。

6. Swift 更快

刪除遺留下來的C語言約定大大提升了引擎蓋之下Swift的性能. Swift代碼性能的基準測試一直都瞄向蘋果公司所致力于的Swift運行app邏輯的速度提升.

根據靈長類動物研究所（Primate Lab）——時下流行的 GeekBench 性能工具的創(chuàng)造者——的調查, 2014年12月中使用曼德爾布羅算法（Mandelbrot algorithm）進行計算密集型任務的性能上蒿秦，Swift已經逼近C++的表現了.

在2015年2月，靈長類動物研究所發(fā)現 Xcode 6.3 測試版提升了Swift在GEMM算法上的性能 -- 這是一種受制于內存限制的算法蛋济，需要對大型數組進行順序訪問 -- 有1.4倍. 初始的FFT實現 -- 這是一種會對大型數組進行隨機訪問的受限于內存的算法 -- 擁有2.6倍的性能提升.

7. 開源項目中更少的名稱沖突

Objective-C 代碼中一直令人很困擾的問題就是缺乏對命名空間的正式支持, 它是 C++ 處理文件名沖突的解決方案棍鳖。當名稱沖突發(fā)生在 Objective-C 中時，就會是一個連接器錯誤碗旅，會導致 app 無法運行渡处。解決的辦法倒是有，可它們都有潛在的隱患祟辟。一般的約定是使用兩到三個字母前綴來區(qū)分編寫的?Objective-C 代碼, 比方說医瘫，通過 Facebook 來展現出你自己的代碼。

Swift 提供了隱含的命名空間旧困，允許相同的代碼文件存在于多個項目醇份，而不會造成構建失敗，或者需要向 NSString (Next Step -- Steve Jobs 被 Apple 炒魷魚之后創(chuàng)建的公司) 或者 CGPoint (Core Graphics)這樣的名稱叮喳。最終被芳，Swift 中的這一特性使得開發(fā)者更加的有生產力，并且也意味著他們沒必要再做 Objective-C 需要的備忘式記憶工作馍悟。在簡單如 Array畔濒，Dictionary 以及 String 這樣的名字中你可以看到 Swift 的影響力，而不是脫胎于缺少命名空間的 Objective-C 中的 NSArray锣咒、NSDictionary 以及 NSString侵状。

8. Swift 支持動態(tài)庫

Swift 中沒有受到足夠重視的一個最大的問題是靜態(tài)庫向動態(tài)庫的切換，其在主要發(fā)布版（iOS8毅整，iOS7等等）會被更新趣兄。動態(tài)庫是可以被鏈接到 app 的可執(zhí)行代碼塊艇潭。這一特性可以讓現有的 Swift 應用可以鏈接到隨著時間推移所產生的更新版本的 Swift 語言鲁纠。

開發(fā)者將 app 連同庫文件一并提交改含，它們都用開發(fā)者證書打上了數字簽名，以確保完整性 (你好, NSA)鞍爱。這就意味著 Swift 可以比 iOS 更快地進化帜慢，對于一種現代編程語言而言這是必要的。對庫文件的修改可以被全部引入 AppStore 上某個 app 的最新更新中拜轨，一起運行起來都如此簡單.

動態(tài)庫在 iOS 上從未受到支持，直到 Swift 和 iOS 8 的發(fā)布颠锉，盡管已經在 Mac 獲得支持很久了拒垃。動態(tài)庫處在應用可執(zhí)行文件之外悼瓮，不過會被包含在從 AppStore 上下載的應用包中。它減小了 app 被加載到內存中的初始大小冠桃，因為外部代碼只在被用到時才會被鏈接進來胸蛛。

9. Swift Playgrounds 鼓勵交互式編碼

Swift 新引入的 Playgrounds 是有經驗的開發(fā)者的福音省咨。Playgrounds 的靈感來自于蘋果公司前雇員 Brett Victor 的工作零蓉。Playgrounds 可以讓程序員用比如說5到20行代碼來測試一種新的算法或者圖形程序，不用去創(chuàng)建一個完整的 iPhone 應用章喉。

蘋果公司已經將內聯代碼執(zhí)行操作加入到了 Playgrounds 中秸脱，以幫助程序員創(chuàng)建代碼塊或者編寫某種算法時獲得反饋摊唇。這樣的反饋循環(huán)可以提升代碼編寫的速度，因為傳統程序員所需要的心智模型已經為 Playground 的數據可視化形式所替代岛请。編程是一個反復的過程崇败，任何可能壓力上的減輕或者創(chuàng)造的補充都會使得開發(fā)者更具生產力僚匆，并能釋放出他們的精力來解決更大的問題，而不是死盯著傳統編譯器來增加程序員的繁瑣細節(jié)松申。

10. Swift 是一個你可以影響的未來

Objective-C 沒有任何出路贸桶，你將不會看到它發(fā)生改變琉历，我們要感謝 Swift 的引入. 一些 Swift 特性可能會集成到 Objective-C, 但 Objective-C 的 C 語言遺留物還是注定了它只能吸收那么點 Swift 的好東西旗笔。