是時(shí)候使用易入手又全面的Swif語(yǔ)言為iOS和mac OS X做應(yīng)用開發(fā)了。
雖然編程語(yǔ)言不會(huì)那么容易消逝,但堅(jiān)持衰落范例的開發(fā)小組正在這么做。如果你正為移動(dòng)設(shè)備開發(fā)應(yīng)用程序,并且你還沒有研究Swift，那么注意:當(dāng)Swift涉及到Mac、iPhone、ipad、Apple Watch和未來(lái)設(shè)備的應(yīng)用開發(fā)時(shí)，它不僅會(huì)排擠掉Objective-C，而且還會(huì)取代在Apple平臺(tái)中做嵌入式開發(fā)的C語(yǔ)言。
由于幾個(gè)關(guān)鍵特性,在未來(lái)幾年，Swift有很大潛力成為創(chuàng)造身臨其境的、響應(yīng)迅速的、面向用戶的應(yīng)用程序的實(shí)際編程語(yǔ)言。
蘋果公司似乎在Swift上還有更大的目標(biāo)。它的編譯器性能和開發(fā)語(yǔ)言都被優(yōu)化了，蘋果公司在Swift的文檔中暗示Swift被設(shè)計(jì)成小能（顯示）“hello,world”，大能（完成）整個(gè)操作系統(tǒng)。蘋果公司還沒把這門語(yǔ)言的目標(biāo)說(shuō)全，Xcode6，Playgrounds和Swift的推出就一起揭露蘋果的意圖：更簡(jiǎn)單的應(yīng)用開發(fā)，更易用的開發(fā)工具鏈。
這是從現(xiàn)在起使用Swift工作，并走在比賽前列的10個(gè)原因。
1. Swift 容易閱讀
如你所能預(yù)計(jì)到的一門基于 C 構(gòu)建的語(yǔ)言，Objective-C 身上所有的毒疣子都有。為了將關(guān)鍵詞和類型同C的類型作區(qū)分，Objective-C 使用@符號(hào)引入了新的關(guān)鍵詞。因?yàn)?Swift 不是基于C構(gòu)建的，它同意了所有的關(guān)鍵詞，并將 Objective-C 類型和對(duì)象相關(guān)的關(guān)鍵詞前面大量的@符號(hào)移除了。
Swift 丟棄了遺留下來(lái)的約定。因而你不再需要行尾的分號(hào)，以及 if/else 語(yǔ)句中圍繞條件表達(dá)式的括弧。另外一個(gè)大變化就是方法的調(diào)用不再互相嵌套成中括號(hào)的深坑 -- 再見吧，[[[ ]]]。Swift 中的方法和函數(shù)的調(diào)用使用行業(yè)內(nèi)標(biāo)準(zhǔn)的在一對(duì)括弧內(nèi)使用逗號(hào)分隔的參數(shù)列表。這樣做的結(jié)果就是一種帶有簡(jiǎn)化了句法和語(yǔ)法的更加干凈有表現(xiàn)力的語(yǔ)言。
除了其它當(dāng)代流行的編程語(yǔ)言之外，Swift 更像是自然的英語(yǔ)了。這種可讀性是的其很容易能被其它來(lái)自 JavaScript，Java，Python，C#，以及 C++ 的開發(fā)者納入到他們的工具鏈之中 -- 一點(diǎn)也不像 Objective-C 這只笨笨的黃小鴨。
2. Swift 更易于維護(hù)
歷史遺留問題會(huì)讓 Objective-C 越來(lái)越倒退 -- C 沒有演進(jìn)的話，這個(gè)語(yǔ)言也就跟著無(wú)法進(jìn)行演進(jìn)。C 需要程序員維護(hù)兩套代碼文件，以優(yōu)化構(gòu)建的時(shí)間以及創(chuàng)建可執(zhí)行 app 的效率, 這種需要延續(xù)到了 Objective-C 上。
Swift 丟掉了對(duì)著倆文件的要求。Swift1.2 中 Xcode 和 LLVM 編譯器可以自動(dòng)計(jì)算出以來(lái)并執(zhí)行增量構(gòu)建。如此，將內(nèi)容清單 (頭文件) 同內(nèi)容主體（實(shí)現(xiàn)文件）相分離。Swift 將 Objective-C 頭文件(.h) 和實(shí)現(xiàn)文件 (.m) 合并成了一個(gè)代碼文件 (.swift）。
Objective-C 的兩份文件系統(tǒng)存在強(qiáng)加給程序員的額外工作 -- 而這些工作會(huì)讓程序員難免分心而不能顧全大局. 在 Objective-C 中你不得不手動(dòng)去同步文件之間的方法名稱和注釋, 有時(shí)候要寄希望于一個(gè)約定好的標(biāo)準(zhǔn)，不過(guò)除非團(tuán)隊(duì)的規(guī)矩和代碼審查制度到位，否則這是不會(huì)為你提供什么保障的。
Xcode 和 LLVM 編譯器可以在幕后做一些工作來(lái)減輕程序員的工作負(fù)擔(dān). 使用 Swift, 程序員可以少做些費(fèi)腦力的記憶性工作，從而能在創(chuàng)建app邏輯的工作上面贏得更多的時(shí)間. Swift 為我們程序員裁掉了那些樣板式的工作，同時(shí)對(duì)代碼、注釋以及所要支持的特性的質(zhì)量都有所提升。
3. Swift 更加安全
Objective-C 有意思的一個(gè)方面是指針 -- 特別是 nil (null) 指針 -- 它們被處理的方式. 在Objective中-C, 如果你調(diào)用方法的是一個(gè)值為 nil (未初始化)的指針變量，什么事情都會(huì)不發(fā)生. 表達(dá)式或者一行操作變成了一項(xiàng)空操作（no-operation (no-op)）, 而這就使得其看起來(lái)會(huì)有不會(huì)奔潰的好處, 但其實(shí)它已經(jīng)變成了一個(gè)巨大的bug來(lái)源. no-op 會(huì)導(dǎo)致不可預(yù)測(cè)的行為, 這是程序員在嘗試找出并修復(fù)某種隨機(jī)的奔潰，或者要停止反常的行為時(shí)所要面對(duì)的敵人。
在Swift代碼中的可選類型使得一個(gè)nil可選值的可能性變得非常的明確, 這意味它能在你寫下一段糟糕的代碼時(shí)會(huì)生成一個(gè)編譯器錯(cuò)誤. 這就建立了一種短程反饋的循環(huán)，可以讓程序員帶著目標(biāo)去寫代碼. 問題在代碼被寫就時(shí)就可以被修復(fù), 這大大節(jié)省了你要在修復(fù)有關(guān)來(lái)自 Objective-C 指針邏輯的bug時(shí)需要耗費(fèi)的時(shí)間和金錢。
在 Objective-C 的傳統(tǒng)中, 如果某個(gè)值返回自一個(gè)方法, （使用注釋以及方法的命名約定來(lái)）說(shuō)明指針變量被返回的行為是程序員的責(zé)任.在 Swift 中, 可選類型和值類型使得方法定義中值是否存在，或者其有可能是可選的（即值可能存在也可能為nil），這些問題都是很明確清楚的。
為了提供對(duì)行為的預(yù)測(cè)，Swift會(huì)在nil可選值被使用時(shí)觸發(fā)一次運(yùn)行時(shí)崩潰。 崩潰提供的就是一種一致的行為，它能減輕修復(fù)bug過(guò)程的壓力，因?yàn)樗鼤?huì)直白地強(qiáng)制讓程序員修復(fù)好這個(gè)問題. Swift 運(yùn)行時(shí)崩潰的時(shí)候會(huì)停在nil可選值被使用到的那行代碼處。這就意味著bug能更早的被修復(fù)，并能在Swift代碼中被完全的規(guī)避掉。
4. Swift 的內(nèi)存管理是統(tǒng)一化的
Swift 以一種 Objective-C 從未有過(guò)的方式進(jìn)行了統(tǒng)一。對(duì)自動(dòng)引用計(jì)數(shù) (ARC) 的支持是在整個(gè)過(guò)程化的和面向?qū)ο蟮拇a路徑上完成的。在。Objective-C。中, ARC 在 Cocoa API 和面向?qū)ο蟠a中獲得支持；然而它并不支持過(guò)程式的 C 語(yǔ)言代碼和像 Core Graphics 這樣的 API。這意味著在使用 Core Graphics API 以及其它 iOS 上的底層 API 時(shí)，內(nèi)存管控的處理都是程序員的責(zé)任。程序員在 Objective-C 上會(huì)遇到的大量?jī)?nèi)存溢出問題在 Swift 上是不可能的。
程序員不應(yīng)該為他或她創(chuàng)建的數(shù)字對(duì)象去考慮內(nèi)存的問題。因?yàn)?ARC 在編譯時(shí)就處理了所有的內(nèi)存管理事務(wù), 內(nèi)存管理所有消耗的腦力現(xiàn)在可以被用來(lái)專注于核心的應(yīng)用邏輯以及新的功能特性。因?yàn)?Swift 中的 ARC 在過(guò)程式的和面向?qū)ο蟮拇a中都能起作用，它也就不再需要程序員進(jìn)行心理上的上下文切換了, 即使是他們?cè)诰帉懸|及底層API的代碼時(shí)也不需要 -- 這在目前版本的 Objective-C 中就是一個(gè)實(shí)實(shí)在在的問題。
自動(dòng)和高性能的內(nèi)存管理是一個(gè)已經(jīng)被解決的問題，而蘋果公司已經(jīng)證明了這個(gè)問題的解決可以提高生產(chǎn)力. 另外一個(gè)副作用就是 Objective-C 和 Swift 不會(huì)像 Java，Go 或者 C# 那樣遇到垃圾收集器針對(duì)沒有被使用的內(nèi)存運(yùn)行清理作業(yè)的情況. 這對(duì)于那些將會(huì)被用于相應(yīng)圖形和用戶輸入的編程語(yǔ)言而言就是一個(gè)非常重要的要素, 特別是在諸如 iPhone、Apple Watch 以及 iPad 這樣的(如果響應(yīng)滯后就會(huì)讓用戶感知上以為應(yīng)用是壞的)觸摸屏設(shè)備上。
5. Swift 代碼更少
Swift 減少了重復(fù)性語(yǔ)句和字符串操作所需要的代碼量。在 Objective-C 中, 使用文本字符串將兩塊信息組合起來(lái)的操作非常繁瑣。Swift 采用當(dāng)代編程語(yǔ)言的特性，比如使用“+”操作符將兩個(gè)字符串加到一起，這在 Objective-C 中是沒有。像這樣支持對(duì)字符和字串的組合對(duì)于任何要在屏幕上向用戶展示文本的編程語(yǔ)言的基礎(chǔ)設(shè)施。
Swift中的類型系統(tǒng)減少了代碼語(yǔ)句的復(fù)雜性--作為編譯器可以理解的類型。比如，Objective-C要求程序員記住特殊字符標(biāo)記（%s，%d，%@）并且提供了一個(gè)用逗號(hào)分隔的變量來(lái)代替每個(gè)標(biāo)記。Swift支持字符串插入，這就消除了需要記住的標(biāo)記和允許程序員直接插入變量到面向用戶的字符串中，比如標(biāo)簽或者按鈕的標(biāo)題。這類推理系統(tǒng)和字符串插入減少錯(cuò)誤來(lái)源在Objective-C中都是很常見的。
在Objective—C中，搞亂了順序或者使用了錯(cuò)誤字符串標(biāo)記會(huì)造成app崩潰。這里，Swift再次將你從反鎖的工作中解放出來(lái)，翻譯成更少要編寫的代碼（代碼現(xiàn)在已經(jīng)不容易出錯(cuò)）因?yàn)樗膶?duì)處理文本字符串和數(shù)據(jù)的內(nèi)嵌支持。
6. Swift 更快
刪除遺留下來(lái)的C語(yǔ)言約定大大提升了引擎蓋之下Swift的性能. Swift代碼性能的基準(zhǔn)測(cè)試一直都瞄向蘋果公司所致力于的Swift運(yùn)行app邏輯的速度提升。
根據(jù)靈長(zhǎng)類動(dòng)物研究所（Primate Lab）——時(shí)下流行的 GeekBench 性能工具的創(chuàng)造者——的調(diào)查, 2014年12月中使用曼德爾布羅算法（Mandelbrot algorithm）進(jìn)行計(jì)算密集型任務(wù)的性能上，Swift已經(jīng)逼近C++的表現(xiàn)了。
在2015年2月，靈長(zhǎng)類動(dòng)物研究所發(fā)現(xiàn) Xcode 6.3 測(cè)試版提升了Swift在GEMM算法上的性能 -- 這是一種受制于內(nèi)存限制的算法，需要對(duì)大型數(shù)組進(jìn)行順序訪問 -- 有1.4倍. 初始的FFT實(shí)現(xiàn) -- 這是一種會(huì)對(duì)大型數(shù)組進(jìn)行隨機(jī)訪問的受限于內(nèi)存的算法 -- 擁有2.6倍的性能提升。
通過(guò)應(yīng)用最佳實(shí)踐，可以觀察到更進(jìn)一步的性能提升, 結(jié)果是 FFT 算法上8.5倍的性能 (差上 C++ 1.1倍)。這些改進(jìn)也使得 Swift 在曼德爾布羅算法上實(shí)際超越了 C++ 1.03 倍。
Swift 在 FFT 和曼德爾布羅算法上幾乎能與 C++ 比肩。根據(jù) Primate Labs 的研究發(fā)現(xiàn)，GEMM 算法的性能表現(xiàn)說(shuō)明 Swift 編譯器還不能實(shí)現(xiàn) C++ 編譯器支持的矢量代碼 -- 所以 Swift 的下一個(gè)版本可能會(huì)比較容易的獲得一次性能提升。
7. 開源項(xiàng)目中更少的名稱沖突
Objective-C 代碼中一直令人很困擾的問題就是缺乏對(duì)命名空間的正式支持, 它是 C++ 處理文件名沖突的解決方案。當(dāng)名稱沖突發(fā)生在 Objective-C 中時(shí)，就會(huì)是一個(gè)連接器錯(cuò)誤，會(huì)導(dǎo)致 app 無(wú)法運(yùn)行。解決的辦法倒是有，可它們都有潛在的隱患。一般的約定是使用兩到三個(gè)字母前綴來(lái)區(qū)分編寫的 Objective-C 代碼, 比方說(shuō)，通過(guò) Facebook 來(lái)展現(xiàn)出你自己的代碼。
Swift 提供了隱含的命名空間，允許相同的代碼文件存在于多個(gè)項(xiàng)目，而不會(huì)造成構(gòu)建失敗，或者需要向 NSString (Next Step -- Steve Jobs 被 Apple 炒魷魚之后創(chuàng)建的公司) 或者 CGPoint (Core Graphics)這樣的名稱。最終，Swift 中的這一特性使得開發(fā)者更加的有生產(chǎn)力，并且也意味著他們沒必要再做 Objective-C 需要的備忘式記憶工作。在簡(jiǎn)單如 Array，Dictionary 以及 String 這樣的名字中你可以看到 Swift 的影響力，而不是脫胎于缺少命名空間的 Objective-C 中的 NSArray、NSDictionary 以及 NSString。
Swift 的命名空間是基于一份代碼文件所屬的目標(biāo)位置。這就意味可以使用命名空間標(biāo)識(shí)來(lái)區(qū)分出不同的類和值。Swift 中的這個(gè)改變很大，它極大的方便了將開發(fā)員項(xiàng)目、框架以及庫(kù)集成到你代碼中來(lái)的操作。命名空間使得在集成開源項(xiàng)目時(shí)，不用擔(dān)心來(lái)自不同軟件公司的同名代碼文件會(huì)發(fā)生沖突。現(xiàn)在 Facebook 和蘋果公司可以同時(shí)使用一個(gè)叫做 FlyingCar.swift 的對(duì)象代碼文件，不會(huì)有任何錯(cuò)誤或者失敗。
8. Swift 支持動(dòng)態(tài)庫(kù)
Swift 中沒有受到足夠重視的一個(gè)最大的問題是靜態(tài)庫(kù)向動(dòng)態(tài)庫(kù)的切換，其在主要發(fā)布版（iOS8，iOS7等等）會(huì)被更新。動(dòng)態(tài)庫(kù)是可以被鏈接到 app 的可執(zhí)行代碼塊。這一特性可以讓現(xiàn)有的 Swift 應(yīng)用可以鏈接到隨著時(shí)間推移所產(chǎn)生的更新版本的 Swift 語(yǔ)言。
開發(fā)者將 app 連同庫(kù)文件一并提交，它們都用開發(fā)者證書打上了數(shù)字簽名，以確保完整性 (你好, NSA)。這就意味著 Swift 可以比 iOS 更快地進(jìn)化，對(duì)于一種現(xiàn)代編程語(yǔ)言而言這是必要的。對(duì)庫(kù)文件的修改可以被全部引入 AppStore 上某個(gè) app 的最新更新中，一起運(yùn)行起來(lái)都如此簡(jiǎn)單。
動(dòng)態(tài)庫(kù)在 iOS 上從未受到支持，直到 Swift 和 iOS 8 的發(fā)布，盡管已經(jīng)在 Mac 獲得支持很久了。動(dòng)態(tài)庫(kù)處在應(yīng)用可執(zhí)行文件之外，不過(guò)會(huì)被包含在從 AppStore 上下載的應(yīng)用包中。它減小了 app 被加載到內(nèi)存中的初始大小，因?yàn)橥獠看a只在被用到時(shí)才會(huì)被鏈接進(jìn)來(lái)。
移動(dòng)應(yīng)用程序或者是 Apple Watch 上的嵌入式應(yīng)用所具有的延遲加載能力，將提升應(yīng)用面向用戶的感知性能。這是使得 iOS 生態(tài)系統(tǒng)更具感官上的響應(yīng)性的區(qū)別之一。蘋果公司原先只專注于運(yùn)行時(shí)加載資料和資源，現(xiàn)在代碼的編譯和鏈接也可以在運(yùn)行時(shí)進(jìn)行。運(yùn)行時(shí)加載減少的等待時(shí)間，直到資源需要被用于展示在屏幕上時(shí)，才會(huì)被加載進(jìn)來(lái)。
Swift 中的動(dòng)態(tài)庫(kù)讓編程語(yǔ)言的修改升級(jí)比以往更快的傳播出去成為了可能。用戶不在需要等待指定的iOS 版本發(fā)布才能享受到 Apple 引入 Swift 中的性能和可靠性改進(jìn)。
9. Swift Playgrounds 鼓勵(lì)交互式編碼
Swift 新引入的 Playgrounds 是有經(jīng)驗(yàn)的開發(fā)者的福音。Playgrounds 的靈感來(lái)自于蘋果公司前雇員 Brett Victor 的工作。Playgrounds 可以讓程序員用比如說(shuō)5到20行代碼來(lái)測(cè)試一種新的算法或者圖形程序，不用去創(chuàng)建一個(gè)完整的 iPhone 應(yīng)用。
蘋果公司已經(jīng)將內(nèi)聯(lián)代碼執(zhí)行操作加入到了 Playgrounds 中，以幫助程序員創(chuàng)建代碼塊或者編寫某種算法時(shí)獲得反饋。這樣的反饋循環(huán)可以提升代碼編寫的速度，因?yàn)閭鹘y(tǒng)程序員所需要的心智模型已經(jīng)為 Playground 的數(shù)據(jù)可視化形式所替代。編程是一個(gè)反復(fù)的過(guò)程，任何可能壓力上的減輕或者創(chuàng)造的補(bǔ)充都會(huì)使得開發(fā)者更具生產(chǎn)力，并能釋放出他們的精力來(lái)解決更大的問題，而不是死盯著傳統(tǒng)編譯器來(lái)增加程序員的繁瑣細(xì)節(jié)。
注意：據(jù)我教授新手程序員的經(jīng)驗(yàn)，Playgrounds 對(duì)于入門者而言不會(huì)像對(duì)有經(jīng)驗(yàn)的程序員那么有用。如果只是簡(jiǎn)單的展示 Swift 中一個(gè)變量是如何工作的，Playggrounds 顯然不能對(duì)幫助新手理解對(duì)于一個(gè)浮點(diǎn)指針變量與一個(gè)整型變量的需要。當(dāng)你要展示一個(gè)能記憶你最后在 Facebook 新聞提要中的滾動(dòng)位置時(shí)，這種需要才會(huì)變得明顯。對(duì)于新手而言，“為什么”這個(gè)問題只能用一個(gè)可以運(yùn)行示例：也就是一個(gè) iPhone 應(yīng)用，來(lái)回答。
10. Swift 是一個(gè)你可以影響的未來(lái)
Objective-C 沒有任何出路，你將不會(huì)看到它發(fā)生改變，我們要感謝 Swift 的引入. 一些 Swift 特性可能會(huì)集成到 Objective-C, 但 Objective-C 的 C 語(yǔ)言遺留物還是注定了它只能吸收那么點(diǎn) Swift 的好東西。
Swift 向開發(fā)者社區(qū)提供了一個(gè)直接的方式，去影響一門語(yǔ)言，它將會(huì)被用于應(yīng)用的創(chuàng)建，嵌入式系統(tǒng)（如果蘋果公司向第三方的嵌入式框架和芯片進(jìn)行了授權(quán)）以及像 Apple Watch 這樣的設(shè)備。
蘋果公司專注于提供最佳的消費(fèi)者體驗(yàn)，而且只構(gòu)建值得注意的功能特性. 隨著 Xcode6.3 中 Swfit1.2 的發(fā)布，蘋果公司已經(jīng)利用流行的 Apple Bug Reporter 工具修復(fù)了數(shù)以千計(jì)的 bug。支撐 Swfit 開發(fā)和改進(jìn)的團(tuán)隊(duì)對(duì)于如何提升語(yǔ)言，以更好的支持那些使用 Swift 構(gòu)建應(yīng)用和系統(tǒng)的開發(fā)社區(qū)很感興趣。
Swift: 更易上手，特性豐富的語(yǔ)言
從丟棄 Objective-C 賴以構(gòu)建的傳統(tǒng)語(yǔ)言開始，一大堆變化讓 Swift 超越了 Objective-C。Apple 并沒有丟棄 Cocoa—— 這是他們的用于創(chuàng)建蘋果風(fēng)格體驗(yàn)的 API 和代碼庫(kù)——而是提供了一個(gè)完整功能的等價(jià)物，使得同支持 Force Touch 或者 Taptic Feedback 這類特性的新 API 交互起來(lái)更加簡(jiǎn)單。
許多舊的設(shè)計(jì)決定都旨在讓編譯器的設(shè)計(jì)更加容易。Swift 則專注于通過(guò)拋棄傳統(tǒng)的緊張心理和編碼實(shí)踐，來(lái)使得應(yīng)用開發(fā)者的工作更加輕松。隨著現(xiàn)代編譯器的發(fā)展，少量的代碼可以表示更多的信息。
使用 Swift，程序員只要維護(hù)原來(lái)一半量的代碼文件，手動(dòng)的代碼同步工作為零，標(biāo)點(diǎn)輸入出錯(cuò)的概率也遠(yuǎn)遠(yuǎn)低于以前 -- 這樣就能騰出更多的時(shí)間寫高質(zhì)量的代碼。通過(guò)使用可選類型 —— 一種針對(duì)返回或不返回值的編譯時(shí)安全機(jī)制，而返回值是同步操作、網(wǎng)絡(luò)失效時(shí)無(wú)效的用戶輸入以及數(shù)據(jù)驗(yàn)證錯(cuò)誤發(fā)生時(shí)普遍會(huì)遇到的問題。ARC 在 Swift 中對(duì)過(guò)程式 C 風(fēng)格的代碼，還有蘋果公司 Cocoa 框架使用的面向?qū)ο蟠a都進(jìn)行了統(tǒng)一。
開發(fā)者會(huì)發(fā)現(xiàn)他們寫的 Swift 比較少，而現(xiàn)代的編程語(yǔ)言特性則支持著他們行行代碼都保持更多的可讀性。隨著其不斷發(fā)展，Swift 會(huì)保持整個(gè)蘋果公司的生態(tài)系統(tǒng)在編程領(lǐng)域的先進(jìn)性，這都要感謝 iOS 和 Swift 中對(duì)動(dòng)態(tài)庫(kù)的支持。開源項(xiàng)目、第三方 SDK 以及框架可以更容易的集成進(jìn)家居自動(dòng)化設(shè)備以及社交服務(wù)中，不會(huì)有編譯時(shí)間的增長(zhǎng)。Swift 在某些算法的速度上幾乎與 C++ 一樣的快，而最新版的Xcode 6.3 和 Swift 1.2 則在這一起跑線上把目標(biāo)指向更多的性能優(yōu)化。
再加上 playgrounds 和 swift 允許用一個(gè)新的方法來(lái)開發(fā)視覺反饋協(xié)助使用內(nèi)聯(lián)數(shù)據(jù)可視化算法程序，讓一個(gè)較短的反饋回路和圖形描述迭代譯碼過(guò)程更容易開始。
最終，Swift 是一個(gè)平易近人的全功能的編程語(yǔ)言，未來(lái)將允許開發(fā)者不僅構(gòu)建 app 還支持嵌入式系統(tǒng)比如新的低功耗 apple watch。
英文原文：Swift vs. Objective-C: 10 reasons the future favors Swift