[[134121]]

各位親愛的iOS與OS X應(yīng)用程序開發(fā)人員，如今正是將編程陣地轉(zhuǎn)移至更為親民、功能更為全面的Swift的最佳時機(jī)。

一般而言，編程語言往往不會輕易消亡，不過由相關(guān)廠商大力推動的更新?lián)Q代舉措則不在此列。如果大家從事移動設(shè)備應(yīng)用程序開發(fā)工作，但卻還沒體驗(yàn)過Swift，那請注意啦：Swift不僅僅是一種希望在Mac、iPhone、iPad、Apple Watch以及其它未來設(shè)備上取代Objective-C的新型編程語言，它同時也將在蘋果平臺上一舉取代C語言對嵌入式編程的統(tǒng)治。

得益于自身的多項(xiàng)關(guān)鍵性特色，Swift正迅速成為我們在未來幾年中創(chuàng)建沉浸式、響應(yīng)式、面向消費(fèi)者的應(yīng)用程序時不容忽視的優(yōu)先性編程語言選項(xiàng)。

蘋果公司似乎為Swift制定了一項(xiàng)宏偉的發(fā)展目標(biāo)。該語言針對編譯器性能以及語言開發(fā)需求作出了諸多優(yōu)化，而且蘋果公司在Swift的說明文檔中暗示稱該語言“在設(shè)計思路上充分考慮到規(guī)模化需要，從‘你好，世界’到完整的操作系統(tǒng)皆可輕松應(yīng)對”。盡管蘋果方面目前還沒有明確指出該語言的設(shè)計目標(biāo)，但Xcode 6、Playgrounds再加上Swift的陸續(xù)出臺標(biāo)志著蘋果公司希望讓應(yīng)用程序開發(fā)工作變得更加輕松，同時這套體系與任意其它開發(fā)工具鏈的對接也將變得簡單便捷。

在今天的文章中，我們將立足于十大理由，了解選擇Swift作為首選編程方案所帶來的具體收益。

1. Swift代碼更易于閱讀

Objective-C幾乎讓大家對于一款以C為基礎(chǔ)建立起的編程語言所抱有的一切預(yù)期及希望都落了空。為了能夠?qū)⒆陨黻P(guān)鍵字與類型設(shè)置與C語言作出區(qū)分，Objective-C引入了@符號作為新的關(guān)鍵字標(biāo)記。由于Swift并非以C語言為建立基礎(chǔ)，因此其能夠?qū)⑺嘘P(guān)鍵字加以統(tǒng)一，同時取消了原本在每種Objective-C類型或者與對象相關(guān)的關(guān)鍵字中的@符號。

Swift徹底丟棄了其前身的大量遺留設(shè)定。因此，大家已經(jīng)沒必要再保證每一行代碼以分號結(jié)尾，或者在if/else語句當(dāng)中利用括號將條件表達(dá)式給括起來。另一大重要變更在于，Swift中的方法調(diào)用不再相互嵌套，這就讓我們從可怕的中括號地獄中解脫了出來——再也不見了，[[[ ]]]。Swift中的方法與函數(shù)調(diào)用采用了業(yè)界標(biāo)準(zhǔn)化的，在圓括號內(nèi)以逗號分隔參數(shù)列表的作法。結(jié)果就是，我們?nèi)缃駬碛辛艘惶赘鼮楹啙崱⒏挥诒憩F(xiàn)力的編程語言，并能夠享受其中更為簡單的語法表達(dá)方式。

Swift的代碼內(nèi)容與英語這一自然語言非常接近，或者說比目前其它主流現(xiàn)代編程語言相比更為接近。這種可讀性使原本使用JavaScript、Java、Python、C#以及C++等語言的程序員能夠更輕松地將Swift納入其工具鏈當(dāng)中——而不像當(dāng)初的丑小鴨Objective-C那么難對付。

2. Swift代碼易于維護(hù)

這種繼承屬性正是Objective-C在發(fā)展中遭遇拖累的主要原因——如果C語言沒有進(jìn)化，那么Objective-C也將無法進(jìn)化。C語言要求程序員同時維護(hù)兩個代碼文件，從而改善構(gòu)建時間并提高應(yīng)用程序創(chuàng)始的執(zhí)行效果，而這一要求也被Objective-C原原本本地繼承了過來。

Swift語言則消除了這種雙文件要求。在Swift 1.2版本中，Xcode與LLVM編譯器已經(jīng)能夠自動判斷出關(guān)聯(lián)性并執(zhí)行增量構(gòu)建。如此一來，將內(nèi)容表（也就是頭文件）從主體（也就是執(zhí)行文件）中剝離出來的任務(wù)已經(jīng)徹底不復(fù)存在。Swift將Objective-C的頭文件（即.h文件）與執(zhí)行文件（即.m文件）整合成了單一代碼文件（即.swift文件）。

Objective-C的雙文件系統(tǒng)無疑給程序員帶來了額外的工作負(fù)擔(dān)——而這讓程序員們更難從大局角度出發(fā)完成開發(fā)任務(wù)。在Objective-C中，我們必須以手動方式在兩個文件之間進(jìn)行方法名及注釋的同步工作，從而讓二者使用同一套標(biāo)準(zhǔn)表達(dá)，但除非開發(fā)團(tuán)隊(duì)已經(jīng)擁有現(xiàn)成的規(guī)則及代碼審查機(jī)制、否則這一目標(biāo)根本得不到保障。

Xcode以及LLVM編譯器能夠在幕后起效以減少程序員的實(shí)際工作量。而在Swift當(dāng)中，程序員幾乎用不著再為上述任務(wù)所煩惱，從而把更多精力及時間用于創(chuàng)建應(yīng)用程序邏輯。Swift簡化了樣板工作、提升了代碼及注釋內(nèi)容的質(zhì)量，同時帶來更多功能支持能力。

3. Swift安全性更高

Objective-C語言的一大有趣之處在于對指針——特別是nil（也就是null）指針——的處理方式。在Objective-C當(dāng)中，如果大家嘗試?yán)媚硞€為nil（即未初始化）的指針變量調(diào)用一項(xiàng)方法，則不會起到任何效果。該表達(dá)式或者代碼行將因此變成無操作（no-op）內(nèi)容，盡管其不至于導(dǎo)致意外崩潰狀況的出現(xiàn)，但卻一直是應(yīng)用程序中各類bug的主要根源。一條no-op往往會導(dǎo)致不可預(yù)知的行為，而這正是程序員們在努力尋找并修正隨機(jī)崩潰或者中止意外狀況時所面臨的頭號大敵。

可靠類型的出現(xiàn)讓無操作值在Swift代碼中的可能后果變得非常明確，這意味著一旦大家編寫出糟糕的代碼、其將直接引發(fā)編譯器錯誤。Swift借此創(chuàng)建出一套簡短的反饋循環(huán)，并允許程序員根據(jù)自己的意圖進(jìn)行編碼。在代碼編寫的過程中、相關(guān)問題就能夠同時得到解決，而這顯然會大大降低我們在bug修復(fù)工作中所投入的時間及精力——特別是與Objective-C指針邏輯相關(guān)的bug。

從傳統(tǒng)角度看，在Objective-C當(dāng)中，如果某個值返回自某個方法，那么程序員就需要負(fù)責(zé)在文件中記錄下該指針返回變量的行為（利用注釋以及方法命名規(guī)則）。而在Swift中，可選類型及值類型的存在使我們能夠很輕松地通過方法定義了解到該值是否存在或者其是否屬于潛在的可選項(xiàng)（即該值可能存在或者可能為nil）。

為了提供具備可預(yù)測性的行為，如果某個nil可選變量被使用、Swift會觸發(fā)一項(xiàng)運(yùn)行時崩潰。這一崩潰會帶來一致性行為，從而簡化了整個bug修復(fù)過程——因?yàn)檫@迫使程序員需要立即對該問題進(jìn)行修復(fù)。此類Swift運(yùn)行時崩潰將阻止對應(yīng)代碼行在出現(xiàn)nil可選變量被使用后繼續(xù)運(yùn)行的狀況。這意味著該bug必須盡快得到修復(fù)，或者被徹底被排除出Swift代碼。

4. Swift在內(nèi)存管理方面擁有統(tǒng)一化特性

Swift能夠以O(shè)bjective-C所無法達(dá)到的方式實(shí)現(xiàn)自身語言的高度統(tǒng)一。Swift對自動引用計數(shù)（即Automatic Reference Counting，簡稱ARC）的支持能力可以完全涵蓋面向過程與面向?qū)ο蟮拇a路徑。在Objective-C當(dāng)中，ARC只能夠在Cocoa API以及面向?qū)ο蟠a內(nèi)部得到支持; 除此之外，其無法作用于C代碼過程以及Core Graphics等API當(dāng)中。這意味著程序員在使用由iOS所提供的Core Graphics API以及其它低級API時，必須自行負(fù)責(zé)內(nèi)存管理工作。有鑒于此，Swift徹底杜絕了程序員經(jīng)常在Objective-C中所面臨的內(nèi)存大規(guī)模泄漏問題。

程序員不應(yīng)該從自己所創(chuàng)建的每個數(shù)字化對象角度考慮內(nèi)存管理工作。由于ARC能夠在編譯的過程中處理所有內(nèi)存管理事務(wù)，因此大家的腦力應(yīng)該專注于應(yīng)用程序的核心邏輯以及各類新功能。由于Swift中的ARC能夠跨越面向過程與面向?qū)ο蟮拇a起效，因此其不再要求程序員把太多精力浪費(fèi)在上下文切換方面——我們甚至能夠直接編寫出觸及底層API的代碼，從而一舉解決Objective-C目前版本所面臨的最大難題。

通過解決自動化與高性能內(nèi)存管理這一難題，蘋果公司用事實(shí)證明了Swift能夠切實(shí)幫助程序員提高生產(chǎn)效率。另一項(xiàng)附加作用在于，Objective-C與Swift都不會受到用于清理未使用內(nèi)存的垃圾收集機(jī)制（即Garbage Collector）的影響，正如Java、Go或者C#一樣。這一點(diǎn)對于任何一種會被用于響應(yīng)圖形及用戶輸入內(nèi)容的編程語言都非常重要，特別是在像iPhone、Apple Watch或者iPad這樣的觸控設(shè)備之上（在這些平臺中，操作滯后會帶來令人難以忍受的糟糕體驗(yàn)，并導(dǎo)致用戶認(rèn)為應(yīng)用程序的運(yùn)行出現(xiàn)了問題）。

5. Swift所需要的代碼較少

Swift對于需要重復(fù)的語句以及字符串操作，Swift能夠大大降低所需代碼量。在Objective-C當(dāng)中，處理文本字符串的過程非常繁瑣，而且需要采取一系列步驟來將兩組信息結(jié)合在一起。相比之下，Swift則具備多種現(xiàn)代編程語言特性，例如通過“+”運(yùn)算符將兩條字符串直接合并在一起，這種能力是Objective-C所不具備的。對于此類字符與字符串結(jié)合方式的支持能力已經(jīng)成為任何一種需要在屏幕上向用戶顯示文本內(nèi)容的編程語言的必備要素。

Swift中的類型系統(tǒng)能夠降低代碼語句的復(fù)雜程度——因?yàn)榫幾g器能夠直接識別出這些類型。舉例來說，Objective-C要求程序員雇特殊的字符串標(biāo)記（例如%s、%d以及%@），并提供一份由逗號分隔的變量列表來替代這些標(biāo)記。Swift支持字符串插值，這就使程序員不必再死記硬背這些標(biāo)記、而能夠直接將變量插入到面向用戶的字符串之內(nèi)，例如標(biāo)簽或者按鈕標(biāo)題。相比之下，Objective-C中的類型推理系統(tǒng)與字符串插值則往往成為導(dǎo)致應(yīng)用崩潰的誘因。

在Objective-C當(dāng)中，弄亂字符串標(biāo)記的順序或者使用了錯誤的字符串標(biāo)記都有可能令應(yīng)用程序發(fā)生崩潰。但現(xiàn)在，Swift能夠把程序員從這些繁瑣的規(guī)定當(dāng)中解放出來，并憑借著其對文本字符串及數(shù)據(jù)操作的內(nèi)聯(lián)支持能力保證翻譯得出的代碼成果更為精練（從而降低了代碼出現(xiàn)錯誤的機(jī)率）。

#p#

6. Swift代碼的執(zhí)行速度更快

從深層角度看，舍棄C語言遺留特性讓Swift在多個方面獲得了巨大提升。Swift代碼在性能基準(zhǔn)測試中的出色表現(xiàn)也證明了，蘋果公司確實(shí)一直在切實(shí)改善Swift運(yùn)行應(yīng)用程序邏輯時的速度水平。

根據(jù)Primate實(shí)驗(yàn)室——也就是高人氣性能工具GeekBench的開發(fā)方——所公布的結(jié)果，Swift在去年12月采用Mandelbrot算法的計算綁定任務(wù)測試中，其性能表現(xiàn)已經(jīng)與C++非常接近。

2015年2月，Primate實(shí)驗(yàn)室發(fā)現(xiàn)Xcode 6.3 Beta版本對Swift在GEMM算法——這是一項(xiàng)內(nèi)存綁定型算法，面向大型數(shù)組進(jìn)行連續(xù)訪問——中的性能表現(xiàn)作出了進(jìn)一步改善，其提升指標(biāo)為1.4。而在最初的FFT算法當(dāng)中——這是一項(xiàng)內(nèi)存綁定型算法，面向大型數(shù)組進(jìn)行隨機(jī)訪問——其性能提升幅度可達(dá)2.6倍。

Swift所采用的一系列最佳實(shí)踐則讓這種改進(jìn)效果變得更為突出，其FFT算法性能測試中的性能提升幅度達(dá)8.5倍（而使用C++時其測試結(jié)果僅為Swift的1.1倍）。這樣的增強(qiáng)效果同時也使得C++在Mandelbrot算法中僅僅獲得了1.03倍于Swift的得分。

Swift語言在FFT與Mandelbrot兩種算法中幾乎已經(jīng)能夠與C++的性能水平相比肩。根據(jù)Primate實(shí)驗(yàn)室的說法，GEMM算法性能測試結(jié)果證明，Swift編譯器無法像C++編譯器那樣實(shí)現(xiàn)代碼量化——而這種量化方式正是快速提升性能表現(xiàn)的便捷途徑，并將在下個版本中正式登陸Swift。

7.減少與開源項(xiàng)目之間的命名沖突

一直困擾著Objective-C代碼的一大問題在于，其缺乏對于命名空間的正式支持能力，而這正是C++在解決代碼文件名沖突時給出的辦法。當(dāng)這種名稱沖突狀況發(fā)生在Objective-C當(dāng)中時，其會表現(xiàn)為一項(xiàng)鏈接錯誤，而且應(yīng)用程序?qū)o法正常運(yùn)行。解決的辦法雖然已經(jīng)出現(xiàn)，但其卻有可能引發(fā)其它潛在問題。一般而言，程序員往往會利用一段由兩個或者三個字母組成的前綴來區(qū)分已經(jīng)編寫完成的Objective-C代碼——換言之，就像是在Facebook上@了我們的代碼一下。

Swift語言提供隱含的命名空間，允許不同項(xiàng)目之間使用同樣的代碼文件名稱，且既不會導(dǎo)致build故障、亦不強(qiáng)制要求程序員使用NNString（即Next Step，是由喬布斯在離開蘋果后創(chuàng)建的公司）或者CGPoint（即Core Graphics）這類命名方式。最后，Swift中的這一特性使得程序員能夠進(jìn)一步提高生產(chǎn)效率，且意味著他們無需再像使用Objective-C時那樣記錄大量文件名稱。在Swift項(xiàng)目中，大家可以看到由這一影響而產(chǎn)生的諸如Array、Dictionary以及String等簡單名稱，而不再像過去那樣被迫使用NSArray、NSDictionary以及NSString等Objective-C缺少命名空間所造成的畸形產(chǎn)物。

在Swift的幫助下，命名空間基于代碼文件歸屬的目標(biāo)所存在。這意味著程序員們能夠利用命名空間標(biāo)識符區(qū)分類或者值。Swift中的這項(xiàng)變更可謂意義重大。這極大地簡化了將開源項(xiàng)目、框架以及庫整合到自有代碼中的流程。該命名空間使得不同軟件廠商能夠創(chuàng)建出同樣的代碼文件名稱，而又無需擔(dān)心在將其與開源項(xiàng)目整合時出現(xiàn)命名沖突。總而言之，現(xiàn)在Facebook與蘋果都能夠使用名為FlyingCar.swift的對象伖雇傭兵，而不會導(dǎo)致任何錯誤或者build故障了。

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

Swift當(dāng)中的最大變化——但同時又沒能受到足夠的重視——當(dāng)數(shù)從以往的靜態(tài)庫經(jīng)歷多次大版本更新（iOS 7、iOS 8以及更多后續(xù)版本）而最終迎來了動態(tài)庫支持。動態(tài)庫屬于可執(zhí)行代碼片段，且能夠被接入到應(yīng)用程序當(dāng)中。這一特性意味著，如今Swift應(yīng)用程序可以隨著Swift語言的不斷發(fā)展隨時與其最新版本相對接。

開發(fā)者需要同時提交應(yīng)用程序及其對應(yīng)庫，而二者都利用開發(fā)證書進(jìn)行了數(shù)字簽名，從而確保其完整性（聽起來美國安全局又能有所作為了）。這意味著Swift語言甚至能夠以高于iOS的速度得到更新，而這也正是現(xiàn)代編程語言的一項(xiàng)重要要求。指向庫的所有變更都能夠被包含在App Store當(dāng)中應(yīng)用程序的最新更新包內(nèi)，而且整個過程的實(shí)現(xiàn)可謂非常簡單。

直到Swift與iOS 8面世之前，iOS系統(tǒng)一直無法支持動態(tài)庫機(jī)制——然而在桌面端，Mac早就已經(jīng)開始對動態(tài)庫提供支持。動態(tài)庫存在于應(yīng)用程序執(zhí)行文件外部，但卻會在用戶從App Store獲取應(yīng)用程序時以綁定方式被一同下載。由于這部分內(nèi)容會被載入到內(nèi)存當(dāng)中，因此其降低了應(yīng)用程序的初始大小，而且這些外部代碼只會在被使用時才得到接入。

在Apple Watch平臺之上，這種在移動應(yīng)用程序或者嵌入式應(yīng)用當(dāng)中實(shí)現(xiàn)延后載入的能力可以提高呈現(xiàn)在用戶使用過程中的性能表現(xiàn)。而這正是iOS生態(tài)系統(tǒng)的一大獨(dú)特之處，即使用體驗(yàn)更為靈敏快捷。蘋果公司一直專注于讓應(yīng)用程序在運(yùn)行過程中僅僅載入所需的資產(chǎn)與資源，而如今經(jīng)過編譯的接入代碼也被納入了這一范疇。這種運(yùn)行過程中即時載入的方式能夠降低應(yīng)用程序的初始等待時間，并保證其直到需要被顯示在屏幕上時才真正被載入。

動態(tài)庫支持能力的出現(xiàn)令Swift成為一款能夠以前所未有的速度實(shí)現(xiàn)變更與改進(jìn)的編程語言。用戶不必再等等iOS的版本更新，即可即時享受到蘋果在Swift當(dāng)中添加的任何性能提升或者可靠性改善效果。

9. Swift Playgrounds鼓勵程序員采取交互式編碼方式

Swift全新引入的Playgrounds正是經(jīng)驗(yàn)豐富的開發(fā)人員們的最大福音。Playgrounds的誕生受到了蘋果公司前任員工Brett Victor的啟發(fā)。Playgrounds能夠幫助程序員實(shí)時測試一種新算法或者圖形例程——例如包含五到二十行代碼——而且無需創(chuàng)建出整套iPhone應(yīng)用程序。

蘋果公司還為Playgrounds添加了內(nèi)聯(lián)代碼執(zhí)行能力，從而幫助程序員在創(chuàng)建一條代碼片段或者編寫一種算法的同時，從開發(fā)環(huán)境處獲得效果反饋。這一反饋循環(huán)能夠大大提高代碼的編寫效率，因?yàn)閺膫鹘y(tǒng)角度講，程序員需要用想法的方式來估計當(dāng)前代碼的運(yùn)行效果——而有了Playgrounds，一直皆以可視化方式進(jìn)行。編程是一種迭代式過程，而其中任何可以減少或者用于補(bǔ)充創(chuàng)建流程的機(jī)制都能讓程序員們更具生產(chǎn)效率，并把他們的精力解放出來用于處理更為重要的問題——而非專注于解決傳統(tǒng)編譯器強(qiáng)加給程序員的那些惱人的細(xì)節(jié)調(diào)整工作。

備注：根據(jù)我個人在教授新人程序員時的感受，Playgrounds的實(shí)際效果對于剛?cè)腴T的新手而言其實(shí)不像經(jīng)驗(yàn)豐富的老鳥們那么突出。單純在Swift Playgrounds當(dāng)中顯示出某條變量的運(yùn)行效果并不能幫助新人們理解這部分代碼到底是需要浮點(diǎn)變量還是整數(shù)變量——是的，如果打算開發(fā)一款能夠記住用戶上一次Facebook新聞內(nèi)容訪問位置的應(yīng)用，這種變量類型的需求將非常顯著。對新手們來說，關(guān)于“為什么”的問題只能在實(shí)現(xiàn)運(yùn)行中的iPhone應(yīng)用里找到答案——而不是Playgrounds上的片段運(yùn)行效果。

10. Swift代表著我們能夠參與并對其產(chǎn)生影響的未來

Objective-C在相當(dāng)長的一段時間里仍將繼續(xù)存在，但其已經(jīng)不會再迎來任何重大改變，而這完全是因?yàn)镾wift的出臺。Swift中的一部分功能可能會被遷移到Objective-C當(dāng)中，但Objective-C脫胎于C語言的血統(tǒng)就注定了它也只能吸收這么一丁點(diǎn)新鮮血液。

Swift語言則給開發(fā)社區(qū)帶來了一種直接的途徑，允許我們每位參與者對其作出影響，并利用最終成果創(chuàng)建應(yīng)用程序、嵌入式系統(tǒng)（如果蘋果未來發(fā)布嵌入式框架許可并向第三方提供芯片架構(gòu)授權(quán)的話）以及像Apple Watch這樣的設(shè)備。

蘋果公司專注于提供最出色的消費(fèi)者使用體驗(yàn)，并正在著手構(gòu)建那些真正值得認(rèn)真關(guān)注的功能特性。隨著Swift 1.2版本在Xcode 6.3中的發(fā)布，蘋果方面已經(jīng)修正了蘋果bug報告所收集到的數(shù)千個已知bug。負(fù)責(zé)支持Swift發(fā)展與演進(jìn)的技術(shù)團(tuán)隊(duì)對該語言的命運(yùn)非常關(guān)注，他們期待著觀察Swift如何實(shí)現(xiàn)更出色的支持效果、從而幫助開發(fā)社區(qū)打造出優(yōu)秀的應(yīng)用程序及系統(tǒng)成果。

Swift:更加平易近人且功能更為齊備的語言選項(xiàng)

前面提到的一系列變更讓Swift得以凌駕于Objective-C之上，同時徹底擺脫了后者作為衍生型語言所殘留的大量固癥頑疾。蘋果公司并不會放棄Cocoa，因?yàn)槠湔莿?chuàng)建出蘋果產(chǎn)品特殊使用體驗(yàn)的核心API及代碼庫。相反，他們會推出功能齊全的校驗(yàn)機(jī)制，并使Cocoa能夠輕松與其它可以支持Force Touch或者Taptic Feedback（即力度感應(yīng)與力反饋）等功能的新型API實(shí)現(xiàn)交互。

過去的許多傳統(tǒng)設(shè)定從設(shè)計思路上看，完全是為了保障編譯器設(shè)計方案的易用性。Swift則將注意力集中在了摒棄傳統(tǒng)編碼實(shí)踐當(dāng)中那些容易令人神經(jīng)緊張的糟粕，從而幫助應(yīng)用程序開發(fā)人員更輕松地完成工作。隨著現(xiàn)代編譯器方案的不斷改進(jìn)，我們將能夠利用更少代碼表達(dá)出更多信息。

有了Swift語言，程序員們需要維護(hù)的代碼文件只相當(dāng)于原先的一半、不必以手動方式進(jìn)行代碼同步、產(chǎn)生標(biāo)點(diǎn)錯誤的可能性也變得更低——這將保證他們將更多時間花在真正具有意義的高質(zhì)量代碼編寫上。在Swift當(dāng)中，代碼現(xiàn)在能夠?qū)崿F(xiàn)自我記錄并提供更多可選類型：編譯時安全機(jī)制會返回某個值或者無值，這恰恰是異步操作、網(wǎng)絡(luò)故障、無效用戶輸入內(nèi)容或者數(shù)據(jù)驗(yàn)證錯誤等多發(fā)問題的根源。在Swift當(dāng)中，ARC在C語言式過程代碼與采用蘋果Cocoa框架的面向?qū)ο蟠a之間得到了統(tǒng)一。

開發(fā)人員會發(fā)現(xiàn)，他們在Swift中需要編寫的代碼量更少，而且能夠借助各類現(xiàn)代語言特性支持自己讓代碼行內(nèi)容變得更為可靠。Swift自身在不斷演變的同時，將始終保證蘋果生態(tài)系統(tǒng)站在編程發(fā)展潮流的前沿，而這都要?dú)w功于iOS與Swift當(dāng)中提供的動態(tài)庫支持能力。與家庭自動化、設(shè)備以及社交服務(wù)相集成的開源項(xiàng)目、第三方SDK以及框架等都將更輕松地實(shí)現(xiàn)對接，而無需忍受由此帶來的額外構(gòu)建時間。Swift在一部分算法測試中幾乎擁有可以與C++相媲美的速度表現(xiàn)，而最新發(fā)布的Xcode 6.3與Swift 1.2版本則標(biāo)志著蘋果將進(jìn)一步推動這一性能優(yōu)化步伐。

而且如今有了Playgrounds的加盟，Swift能夠以一種全新方式為程序員提供可視性反饋信息，從而幫助我們利用內(nèi)聯(lián)數(shù)據(jù)可視化機(jī)制實(shí)現(xiàn)算法開發(fā)。由于反饋循環(huán)更短且提供圖形化描述，迭代編碼過程也要比原先更為簡便。

最后讓我們進(jìn)行一番總結(jié)：Swift是一款平易近人且功能齊備的編程語言，不僅允許開發(fā)人員利用它構(gòu)建應(yīng)用程序、同時也將發(fā)展目標(biāo)指向了未來多年內(nèi)將陸續(xù)出現(xiàn)的Apple Watch等新型低功耗嵌入式系統(tǒng)平臺。