一、iOS7 SDK新特性

1、UI相關

簡單總結來說，以現在上手體驗看來新的UI變化改進有如下幾點：

• 狀態欄，導航欄和應用實際展示內容不再界限：系統自帶的應用都不再區分狀態欄和navigation bar，而是用統一的顏色力求簡潔。這也算是一種趨勢。
• BarItem的按鈕全部文字化：這點做的相當堅決，所有的導航和工具條按鈕都取消了擬物化，趨於扁平化設計。原來的文字（比如“Edit”，“Done”之類）改為了簡單的文字，原來的圖標（比如新建或者刪除）也做了簡化。

所謂“扁平化設計”指的是拋棄漸變、陰影、高光等擬物視覺效果，從而打造出一種看上去更“平”的界面。也就是說，扁平化設計是與擬物化（Skeuomorphism）設計相對的一個設計理念。扁平化設計最好的理解是“極簡”，即強調運用最輕量、簡單的設計來傳遞核心信息，強調通過對視覺焦點的引導來讓用戶快速地完成操作。

• 程序打開加入了動畫：從主界面到圖標所在位置的一個放大，同時顯示應用的載入界面。

UIKit的力學模型（UIKit Dynamics

UIKit動力學vcat.com/2013/06/uikit-dynamics-started/" target="_blank">WWDC2013筆記 UIKit力學模型入門http://onevcat.com/2013/06/uikit-dynamics-started/

新增了UIDynamicItem委托，用來為UIView制定力學模型行為，當然其他任何對象都能通過實現這組接口來定義動力學行為，只不過在UIKit中可能應用最多。所謂動力學行為，是指將現實世界的我們常見的力學行為或者特性引入到UI中，比如重力等。通過實現UIDynamicItem，UIKit現在支持如下行為：

• UIAttachmentBehavior 連接兩個實現了UIDynamicItem的物體（以下簡稱動力物體），一個物體移動時，另一個跟隨移動
• UICollisionBehavior 指定邊界，使兩個動力物體可以進行碰撞
• UIGravityBehavior 顧名思義，為動力物體增加重力模擬
• UIPushBehavior 為動力物體施加持續的力
• UISnapBehavior 為動力物體指定一個附著點，想象一下類似掛一幅畫在圖釘上的感覺

如果有開發游戲的童鞋可能會覺得這些很多都是做游戲時候的需求，一種box2d之類的2D物理引擎的既視感躍然而出。沒錯的親，動態UI，加上之後要介紹的Sprite Kit，極大的擴展了使用UIKit進行游戲開發的可能性。另外要注意UIDynamicItem不僅適用於UIKit，任何對象都可以實現接口來獲得動態物體的一些特性，所以說用來做一些3D的或者其他奇怪有趣的事情也不是沒有可能。如果覺得Cocos2D+box2d這樣的組合使用起來不方便的話，現在動態UIKit+SpriteKit給出了新的選擇。

2、游戲方面

Sprite Kit Framework

這是個人認為iOS7 SDK最大的亮點，也是最重要的部分，iOS SDK終於有自己的精靈系統了。Sprite Kit Framework使用硬件加速的動畫系統來表現2D和2.5D的游戲，它提供了制作游戲所需要的大部分的工具，包括圖像渲染，動畫系統，聲音播放以及圖像模擬的物理引擎。可以說這個框架是iOS SDK自帶了一個較完備的2D游戲引擎，力圖讓開發者專注於更高層的實現和內容。和大多數游戲引擎一樣，Sprite Kit內的內容都按照場景（Scene）來分開組織，一個場景可以包括貼圖對象，視頻，形狀，粒子效果甚至是CoreImage濾鏡等等。相對於現有的2D引擎來說，由於Sprite Kit是在系統層級進行的優化，渲染時間等都由框架決定，因此應該會有比較高的效率。

另外，Xcode還提供了創建粒子系統和貼圖Atlas的工具。使用Xcode來管理粒子效果和貼圖atlas，可以迅速在Sprite Kit中反應出來。

Game Controller Framework

為Made-for-iPhone/iPod/iPad (MFi) game controller設計的硬件的對應的框架，可以讓用戶用來連接和控制專門的游戲硬件。參考WWDC 2013開場視頻中開始的賽車演示。現在想到的是，也許這貨不僅可以用於游戲…或者蘋果之後會擴展其應用，因為使用普及率很高的iPhone作為物聯網的入口，似乎會是很有前途的事情。

3、多任務強化

後台應用運行和多任務新特性WWDC2013筆記 iOS7中的多任務http://onevcat.com/2013/08/ios7-background-multitask/

• 經常需要下載新內容的應用現在可以通過設置UIBackgroundModes為fetch來實現後台下載內容了，需要在AppDelegate裡實現setMinimumBackgroundFetchInterval:以及application:performFetchWithCompletionHandler:來處理完成的下載，這個為後台運行代碼提供了又一種選擇。不過考慮到Apple如果繼續嚴格審核的話，可能只有雜志報刊類應用能夠取得這個權限吧。另外需要注意開發者僅只能指定一個最小間隔，最後下沒下估計就得看系統娘的心情了。
• 同樣是後台下載，以前只能推送提醒用戶進入應用下載，現在可以接到推送並在後台下載。UIBackgroundModes設為remote-notification，並實現application:didReceiveRemoteNotification:fetchCompletionHandler:

為後台下載，開發者必須使用一個新的類NSURLSession，其實就是在NSURLConnection上加了個後台處理，使用類似，API十分簡單，不再贅述。

4、地圖

Apple在繼續在地圖應用上的探索，MapKit的改進也乏善可陳。我一直相信地圖類應用的瓶頸一定在於數據，但是對於數據源的建立並不是一年兩年能夠完成的。Google在這一塊憑借自己的搜索引擎有著得天獨厚的優勢，蘋果還差的很遠很遠。看看有哪些新東西吧：

• MKMapCamera，可以將一個MKMapCamera對象添加到地圖上，在指明位置，角度和方向後將呈現3D的樣子…大概可以想象成一個數字版的Google街景..
• MKDirections 獲取Apple提供的基於方向的路徑，然後可以用來將路徑繪制在自己的應用中。這可能對一些小的地圖服務提供商產生沖擊，但是還是那句話，地圖是一個數據的世界，在擁有完備數據之前，Apple不是Google的對手。這個狀況至少會持續好幾年（也有可能是永遠）。
• MKGeodesicPolyline 創建一個隨地球曲率的線，並附加到地圖上，完成一些視覺效果。
• MKMapSnapshotter 使用其拍攝基於地圖的照片，也許各類簽到類應用會用到
• 改變了overlay物件的渲染方式

5、點對點連接 Peer-to-Peer Connectivity

可以看成是AirDrop不能直接使用的補償，代價是需要自己實現。MultipeerConnectivity框架可以用來發現和連接附近的設備，並傳輸數據，而這一切並不需要有網絡連接。可以看到Apple逐漸在文件共享方面一步步放開限制，但是當然所有這些都還是被限制在sandbox裡的。

6、Store Kit Framework

Store Kit在內購方面采用了新的訂單系統，這將可以實現對訂單的本機驗證。這是一次對應內購破解和有可能驗證失敗導致內購失敗的更新，蘋果希望藉此減少內購的實現流程，減少出錯，同時遏制內購破解泛濫。前者可能沒有問題，但是後者的話，因為objc的動態特性，決定了只要有越獄存在，內購破解也是早晚的事情。不過這一點確實方便了沒有能力架設驗證服務器的小開發者，這方面來說還是很好的。

二、iOS8 SDK新特性

1、應用擴展 (Extension)

這是一個千呼萬喚始出來的特性，也是一個可以發揮無限想象力的特性。現在 Apple 允許我們在 app 中添加一個新的 target，用來提供一些擴展功能：比如在系統的通知中心中顯示一個自己的 widget，在某些應用的 Action 中加入自己的操作，在分享按扭裡加入自己的條目，更甚至於添加自定義的鍵盤等等。每一種操作對應這一個應用擴展的入口，在開發中我們只需要在工程中新建立一個對應相應入口的 target，就能從一個很好的模板開始進行一些列開發，來實現這些傳統意義上可能需要越獄才能實現的功能。

對於應用擴展，Apple 將其定義為 App 的功能的自然延伸，因此不是單獨存在的，而是隨著應用本體的包作為附屬而被一同下載和安裝到用戶的設備中的，用戶需要在之後選擇將其開啟。

2、App 開發時的統一

隨著一代代的 iPhone 和 iPad 的出現，iOS 設備的屏幕尺寸也開始出現分裂的趨勢。之前一套屏幕兩個方向吃遍全世界的美好時光已然不再，現在至少已經有 3.5 寸，4寸和 10(7) 寸三種分辨率/尺寸的機型需要進行適配，再考慮到每個尺寸的橫豎兩種方向，以及日益呼聲愈高的 4.7 寸和 5.5 寸的 iPhone，可以相見現在的布局方式已然不堪重負。雖然在 iOS 6 Apple 就推出了 Auto Layout 來輔助完成布局工作，解決了原來的相對布局的一些問題，但是在以絕對尺寸為度量的坐標系統中，難免還是有所掣肘。在 iOS 8 中，Apple 的工程師們可以說“極富想象力”地干脆把限制和表征屏幕尺寸的長寬數字給去掉了，取而代之使用 size classes 的概念，將長寬尺寸按照設備類型和方向歸類為 regular 和 compact 兩類。通過為不同的設備定義尺寸分類，用來定義同類型的操作特性，這使得開發者更容易利用一套 UI 來適配不同的屏幕。

iOS 8 在 UIKit 中添加了一整套使用 size classes 來進行布局的 API，並且將原有的比較復雜（或者說有些冗余）的 API 作廢了。結合新的 Interface Builder 和 Auto Layout，可以說對於多尺寸屏幕的適配得到了前所未有的簡化。

Auto Layout 正如其名，只是一個根據約束來進行布局的方案，而在對應不同設備的具體情況下的體驗上還有欠缺。一個最明顯的問題是它不能根據設備類型來確定不同的交互體驗。很多時候你還是需要判斷設備到底是 iPhone 還是 iPad，以及現在的設備方向究竟是豎直還是水平來做出判斷。

不再根據設備屏幕的具體尺寸來進行區分，而是通過它們的感官表現，將其分為普通(Regular) 和緊密(Compact) 兩個種類 (class)。開發者便可以無視具體的尺寸，而是對這這兩類和它們的組合進行適配。這樣不論在設計時還是代碼上，我們都可以不再受限於具體的尺寸，而是變成遵循尺寸的視覺感官來進行適配。

簡單來說，現在的 iPad 不論橫屏還是豎屏，兩個方向均是 Regular 的；而對於 iPhone，豎屏時豎直方向為 Regular，水平方向是 Compact，而在橫屏時兩個方向都是 Compact。要注意的是，這裡和談到的設備和方向，都僅僅只是為了給大家一個直觀的印象。相信隨著設備的變化，這個分類也會發生變動和更新。Size Classes 的設計哲學就是尺寸無關，在實際中我們也應該盡量把具體的尺寸拋開腦後，而去盡快習慣和適應新的體系。

為了表征 Size Classes，Apple 在 iOS 8 中引入了一個新的類，UITraitCollection。這個類封裝了像水平和豎直方向的 Size Class 等信息。iOS 8 的 UIKit 中大多數 UI 的基礎類 (包括UIScreen，UIWindow，UIViewController和UIView) 都實現了UITraitEnvironment這個接口，通過其中的traitCollection這個屬性，我們可以拿到對應的UITraitCollection對象，從而得知當前的 Size Class，並進一步確定界面的布局。

和 UIKit 中的響應者鏈正好相反，traitCollection將會在 view hierarchy 中自上而下地進行傳遞。對於沒有指定traitCollection的 UI 部件，將使用其父節點的traitCollection。這在布局包含 childViewController 的界面的時候會相當有用。在UITraitEnvironment這個接口中另一個非常有用的是-traitCollectionDidChange:。在traitCollection發生變化時，這個方法將被調用。在實際操作時，我們往往會在 ViewController 中重寫-traitCollectionDidChange:或者-willTransitionToTraitCollection:withTransitionCoordinator:方法 (對於 ViewController 來說的話，後者也許是更好的選擇，因為提供了轉場上下文方便進行動畫；但是對於普通的 View 來說就只有前面一個方法了)，然後在其中對當前的traitCollection進行判斷，並進行重新布局以及動畫。代碼看起來大概會是這個樣子：

- (void)willTransitionToTraitCollection:(UITraitCollection *)newCollection 
              withTransitionCoordinator:(id )coordinator
{
    [super willTransitionToTraitCollection:newCollection 
                 withTransitionCoordinator:coordinator];
    [coordinator animateAlongsideTransition:^(id  context) {
        if (newCollection.verticalSizeClass == UIUserInterfaceSizeClassCompact) {
            //To Do: modify something for compact vertical size
        } else {
            //To Do: modify something for other vertical size
        }
        [self.view setNeedsLayout];
    } completion:nil];
}

在兩個 To Do 中，我們應該刪除或者添加或者更改不同條件下的 Auto Layout 約束 (當然，你也可以干其他任何你想做的事情)，然後調用-setNeedsLayout來在上下文中觸發轉移動畫。如果你堅持用代碼來處理的話，可能需要面臨對於不同 Size Classes 來做移除舊的約束和添加新的約束這樣的事情，可以說是很麻煩 (至少我覺得是麻煩的要死)。但是如果我們使用 IB 的話，這些事情和代碼都可以省掉，我們可以非常方便地在 IB 中指定各種 Size Classes 的約束 (稍後會介紹如何使用 IB 來對應 Size Classes)。另外使用 IB 不僅可以節約成百上千行的布局代碼，更可以從新的 Xcode 和 IB 中得到很多設計時就可以實時監視，查看並且調試的特性。可以說手寫 UI 和使用 IB 設計的時間消耗和成本差距被進一步拉大，並且出現了很多手寫 UI 無法實現，但是 IB 可以不假思索地完成的任務。從這個意義上來說，新的 IB 和 Size Classes 系統可以說無情地給手寫代碼判了個死緩。

另外，新的 API 和體系的引入也同時給很多我們熟悉的 UIViewController 的有關旋轉的老朋友判了死刑，比如下面這些 API 都棄用了：

@property(nonatomic, readonly) UIInterfaceOrientation interfaceOrientation

- willRotateToInterfaceOrientation:duration:
- willAnimateRotationToInterfaceOrientation:duration:
- didRotateFromInterfaceOrientation:
- shouldAutomaticallyForwardRotationMethods

現在全部統一到了viewWillTransitionToSize:withTransitionCoordinator:，旋轉的概念不再被提倡使用。其實仔細想想，所謂旋轉，不過就是一種 Size 的改變而已，我們都被 Apple 騙了好多年，不是麼？

在 Interface Builder 中使用 Size Classes

第一次接觸 Xcode 6 和打開 IB 的時候你可能會驚呼，為什麼我的畫布變成正方形了。我在第一天 Keynote 結束後在 Moscone Center 的食堂裡第一次打開的時候，還滿以為自己找到了 iWatch 方形顯示屏的確鑿證據。到後來才知道，這是新的 Size Classes 對應的編輯方式。

既然我們不需要關心實際的具體尺寸，那麼我們也就完全沒有必要在 IB 中使用像 3.5/4 寸的 iPhone 或是 10 寸的 iPad 來分開對界面進行編輯。使用一個通用的具有 "代表" 性質的尺寸在新體系中確實更不容易使人迷惑。

在現在的 IB 界面的正下方，你可以看到一個wAny hAny的按鈕 (因為今年 NDA 的一個明確限制是不能發相關軟件截圖，雖然其實可能沒什麼太大問題，但是還是尊重 license 比較好)，這代表現在的 IB 是對應任意高度和任意寬度的。點擊後便可以選擇需要為哪種 Size Class 進行編輯。默認情況在 Any Any 下的修改會對任意設備和任意方向生效，而如果先進行選擇後再進行編輯，就表示編輯只對選中的設定生效。這樣我們就很容易在同一個 storyboard 文件裡對不同的設備進行適配：按照設備需要添加或者編輯某些約束，或者是在特定尺寸下隱藏某些 view (使用 Attribute Inspector 裡的Installed選框的加號添加)。這使得使用 IB 制作通用程序變簡單了，我們不再需要為 iPhone 和 iPad 准備兩套 storyboard 了。

可以發揮的想象空間實在太大，一套界面布局通吃所有設備的畫面太美好，我都不敢想。

Size Classes 和 Image Asset 及 UIAppearence

Image Asset 裡也加入了對 Size Classes 的支持，也就是說，我們可以對不同的 Size Class 指定不同的圖片了。在 Image Asset 的編輯面板中選擇某張圖片，Inspector 裡現在多了一個 Width 和 Height 的組合，添加我們需要對應的 Size Class， 然後把合適的圖拖上去，這樣在運行時 SDK 就將從中挑選對應的 Size 的圖進行替換了。不僅如此，在 IB 中我們也可以選擇對應的 size 來直接在編輯時查看變化(新的 Xcode 和 IB 添加了非常多編輯時的可視化特性，關於這方面我有計劃單獨寫一篇可視化開發的文章進行說明)。

這個特性一個最有用的地方在於對於不同屏幕尺寸可能我們需要的圖像尺寸也有所不同。比如我們希望在 iPhone 豎屏或者 iPad 時的按鈕高一些，而 iPhone 橫屏時由於屏幕高度實在有限，我們希望得到一個扁一些的按鈕。對於純色按鈕我們可以通過簡單的約束和拉伸來實現，但是對於有圖案的按鈕，我們之前可能就需要在 VC 裡寫一些髒代碼來處理了。現在，只需要指定好特定的 Image Asset，然後配置合適的 (比如不含有尺寸限制) 約束，我們就可以一行代碼不寫，就完成這樣復雜的各個機型和方向的適配了。

實際做起來實在是太簡單了..但拿個 demo 說明一下吧，比如下面這個實現了豎直方向 Compact 的時候將笑臉換成哭臉 -- 當然了，一行代碼都不需要。

另外，在 iOS 7 中 UIImage 添加了一個renderingMode屬性。我們可以使用imageWithRenderingMode:並傳入一個合適的UIImageRenderingMode來指定這個 image 要不要以Template 的方式進行渲染。在新的 Xcode 中，我們可以直接在 Image Asset 裡的Render As選項來指定是不是需要作為 template 使用。而相應的，在UIApperance中，Apple 也為我們對於 Size Classes 添加了相應的方法。使用+appearanceForTraitCollection:方法，我們就可以針對不同 trait 下的應用的 apperance 進行很簡單的設定。比如在上面的例子中，我們想讓笑臉是綠色，而哭臉是紅色的話，不要太簡單。首先在 Image Asset 裡的渲染選項設置為Template Image，然後直接在AppDelegate裡加上這樣兩行：

UIView.appearanceForTraitCollection(UITraitCollection(verticalSizeClass:.Compact)).tintColor = UIColor.redColor()
UIView.appearanceForTraitCollection(UITraitCollection(verticalSizeClass:.Regular)).tintColor = UIColor.greenColor()

 

UIViewController 的表現方式

UISplitViewController

 

在用 Regular 和 Compact 統一了 IB 界面設計之後，Apple 的工程師可能發現了一個讓人兩難的歷史問題，這就是UISplitViewController。一直做 iPhone 而沒太涉及 iPad 的童鞋可能對著這個類不是很熟悉，因為它們是 iPad Only 的。iPad 推出時為了適應突然變大的屏幕，並且遠離 "放大版 iTouch" 的诟病，Apple 為 iPad 專門設計了這個主從關系的 ViewControlle容器。事實也證明了這個設計在 iPad 上確實是被廣泛使用，是非常成功的。

現在的問題是，如果我們只有一套 UI 畫布的話，我們要怎麼在這個單一的畫布上處理和表現這個 iPad Only 的類呢？

答案是，讓它在 iPhone 上也能用就行了。沒錯，現在你可以直接在 iPhone 上使用 SplitViewController 了。在 Regular 的寬度時，它保持原來的特性，在 DetailViewController 中顯示內容，這是毫無疑問的。而在 Compact 中，我們第一想法就是以 push 的表現形式展示。在以前，我們可能需要寫不少代碼來處理這些事情，比如在 AppDelegate 中就在一開始判斷設備是不是 iPad，然後為應用設定兩套完全不同的導航：一套基於UINavigationController，另一套基於UISplitViewController。而現在我們只需要一套UISplitViewController，並將它的 MasterViewController 設定為一個 navgationController 就可以輕松搞定所有情況了。

也許你會想，即使這樣，我是不是還是需要判斷設備是不是 iPad，或者現在的話是判斷 Size Class 是不是 Compact，來決定是要做的到底是 navVC 的 push 還是改變 splitVC 的 viewControllers。其實不用，我們現在可以無痛地不加判斷，直接用統一的方式來完成兩種表現方式。這其中的奧妙在於我們不需要使用 (事實上 iOS 8 後 Apple 也不再提倡使用)UINavigationController的pushViewController:animated:方法了 (又一個老朋友要和我們說再見了)。其實雖然很常用，但是這個方法是一直受到社區的議論的：因為正是這個方法的存在使得 ViewController 的耦合特性上了一個檔次。在某個 ViewController 中這個方法的存在時，就意味著我們需要確保當前的 ViewController 必須處於一個導航棧的上下文中，這是完全和上下文耦合的一種方式 (雖然我們也可以很蛋疼地用判斷navController是不是nil來繞開，但是畢竟真的很丑，不是麼)。

我們現在有了新的展示 viewController 的方法，-showViewController:sender:以及-showDetailViewController:sender:。調用這兩個方法時，將順著包括調用 vc 自身的響應鏈而上，尋找最近的實現了這個方法的 ViewController 來執行相應代碼。在 iOS SDK 的默認實現中，在UISplitViewController這樣的容器類中，已經有這兩個方法的實現方式，而UINavigationController也實現了-showViewController:sender:的版本。對於在 navController 棧中的 vc，會調用 push 方式進行展示，而對 splitVC，showViewController:sender:將在 MasterViewController 中進行 push。而showDetailViewController:sender:將根據水平方向的 Size 的情況進行選擇：對於 Regular 的情況，將在 DetailViewController 中顯示新的 vc，而對於 Compact 的情況，將由所在上下文情況發回給下級的 navController 或者是直接以 modal 的方式展現。關於這部分的具體內容，可以仔細看看這個示例項目和相關的文檔 (beta版)。

這麼設計的好處是顯而易見的，首先是解除了原來的耦合，使得我們的 ViewController 可以不被局限於導航控制器上下文中；另外，這幾個方法都是公開的，也就是說我們的 ViewController 可以實現這兩個方法，截斷響應鏈的響應，並實現我們自己的呈現方式。這在自定義 Container Controller 的時候會非常有用。

UIPresentationController

iOS 7 中加入了一套實現非常漂亮的自定義轉場動畫的方法 (如果你還不知道或者不記得了，可以看看我去年的這篇筆記)。Apple 在解耦和重用上的努力確實令人驚歎。而今年，順著自適應和平台開發統一的東風，在呈現 ViewController 的方式上 Apple 也做出了從 iOS SDK 誕生以來最大的改變。iOS 8 中新加入了一個非常重要的類UIPresentationController，這個NSObject的子類將用來管理所有的 ViewController 的呈現。在實現方式上，這個類和去年的自定義轉場的幾個類一樣，是完全解耦合的。而 Apple 也在自己的各種 viewController 呈現上完全統一地使用了這個類。

再見 UIPopoverController

和 SplitViewController 類似，UIPopoverController原來也只是 iPad 使用的，現在 iPhone 上也將適用。准確地說，現在我們不再使用UIPopoverController這個類 (雖然現在文檔還沒有將其標為 deprecated，但是估計也是遲早的事兒了)，而是改用一個新的類UIPopoverPresentationController。這是UIPresentationController的子類，專門用來負責呈現以 popover 的形式呈現內容，是 iOS 8 中用來替代原有的UIPopoverController的類。

比起原來的類，新的方式有什麼優點呢？最大的優勢是自適應，這和UISplitViewController在 iOS 8 下的表現是類似的。在 Compact 的寬度條件下，UIPopoverPresentationController的呈現將會直接變成 modal 出來。這樣我們基本就不再需要去判斷 iPhone 還是 iPad (其實相關的判定方法也已經被標記成棄用了)，就可以對應不同的設備了。以前我們可能要寫類似這樣的代碼：

if UIDevice.currentDevice().userInterfaceIdiom == .Pad {
    let popOverController = UIPopoverController(contentViewController: nextVC)
    popOverController.presentPopoverFromRect(aRect, inView: self.view, permittedArrowDirections: .Any, animated: true)
} else {
    presentViewController(nextVC, animated: true, completion: nil)
}

而現在需要做的是：

nextVC.modalPresentationStyle = .Popover
let popover = nextVC.popoverPresentationController
popover.sourceRect = aRect
popover.permittedArrowDirections = .Any

presentViewController(nextVC, animated: true, completion: nil)

沒有可惡的條件判斷，一切配置井井有條，可讀性也非常好。

除了自適應之外，新方式的另一個優點是非常容易自定義。我們可以通過繼承UIPopoverPresentationController來實現我們自己想要的呈現方式。其實更准確地說，我們應該繼承的是UIPresentationController，主要通過實現-presentationTransitionWillBegin和-presentationTransitionDidEnd:來自定義我們的展示。像以前我們想要實現只占半個屏幕，後面原來的 view 還可見的 modal，或者是將從下到上的動畫改為百葉窗或者漸隱漸現，那都是可費勁兒的事情。而在UIPresentationController的幫助下，一切變得十分自然和簡單。在自己的UIPresentationController子類中：

override func presentationTransitionWillBegin() {
    let transitionCoordinator = self.presentingViewController.transitionCoordinator()
    transitionCoordinator.animateAlongsideTransition({context in
        //Do animation here
    }, completion: nil)
}

override func presentationTransitionDidEnd(completed: Bool)  {
    //Do clean here
}

具體的用法和 iOS 7 裡的自定義轉場很類似，設定需要進行呈現操作的 ViewController 的 transition delegate，在UIViewControllerTransitioningDelegate的-presentationControllerForPresentedViewController:sourceViewController:方法中使用-initWithPresentedViewController:presentingViewController:生成對應的UIPresentationController子類對象返回給 SDK，然後就可以喝茶看戲了。

不僅如此，像是原來 iPad 專有的 SplitController 等也被以適應不同 regular 和 compact 的尺寸類型的形式 port 到了 iPhone 上，在程序設計方面兩者更加統一了。另外，一直陪伴我們的UIAlertView和UIActionSheet這些老面孔也將退出舞台，取而代之全部統一以 UIViewController 來呈現。

這是一個好的開始，也是一個好的變化。可以看到 Apple 在避免平台碎片化上正在努力。

3、Health Kit 和 Home Kit

這是對應兩個現在很熱的領域 -- 可穿戴式設備和智能家電 -- 所加入的框架。基本上來說 Apple 想做的事情就是以 iOS 為基礎，為其他 app 建立一個平台以及成為用戶數據的管理者。

Health Kit 就是一個用戶體征參數的數據庫，第三方應用可以向用戶申請權限使用其中的數據或是向其中匯報數據。而 Home Kit 則以家庭，房間和設備的組織形式來管理和控制家中適配了 Home Kit 的智能家電。這兩個超級年輕的框架的 API 相對都還比較簡單，結構也很好，相信稍有經驗的 iOS 開發者都能在很快掌握用法。唯一的限制在於作為普通開發者（比如我這樣的只能自己業余玩的）可能手邊現在不會有合適的設備來進行測試，所以很多東西其實沒有辦法驗證。不過對於 Home Kit，Apple給我們提供了一個模擬器來模擬智能家電設備，您可以在 Xcode 6 的 Open Developer Tool 菜單中找到 Home Kit Accessory Simulator。使用模擬器可以發現，添加並且控制自定義的智能家電，用來前期開發還是蠻方便的。

4、游戲方面

最大的改變莫過於 Scene Kit 的加入了。不過游戲天生的容易跨平台的特性 (並且也有這方面的強烈需求)，與平台限制的 Sprite Kit 是沖突的，所以去年的 Sprite Kit 也還沒多少人用。暫時看來這個世界現在是，並且在一段時間內還會是被 Cocos2dx/Unity 所統治的。Scene Kit 的未來估計會和 Sprite Kit 比較類似，作為對於一直進行 iOS 應用開發的開發者來說，有著不需要學習和熟悉新語言的優勢，容易與系統的其他框架進行集成，所以用來轉型還算不錯的選擇。但除此之外其他方面可能也並沒有多少可以吸引人的地方了。

另一個重大改變是對於 A7 和以上級別的 GPU 推出了一套全新的稱為 Metal 的繪制 API，從 Keynote 的 Zen Garden 的演示來看，Metal 的性能毋庸置疑是令人折服的，Metal 的渲染方式和著色器也相當有趣。但是其實這些內容更多地是偏向底層以及面向引擎開發的，對於使用游戲引擎來制作游戲的大多數開發者來說，並不需要知道或者理解其中的東西。在 A7 的芯片下使用 Apple 自家的 Sprite Kit 或者 Scene Kit 的話，就可以直接受益於 Metal，而其他一些知名的第三方引擎，比如 Unity 和 UE 也都會在 iOS 8 推出後支持 Metal。因此，作為引擎使用者，並不需要做出除了升級開發使用的游戲引擎之外的任何改變。

5、其他方面的改動

 

A、 Local 和 Remote 通知的變化

 

現在需要顯示 UI 或者播放聲音的通知，包括 Local 通知也需要實現彈窗獲得用戶許可了。使用-registerUserNotificationSettings:來向用戶獲取許可。作為補償，現在對於不需要打擾用戶（也就是 iOS 7 加入的靜默通知）的類型不再需要彈框獲取用戶許可。不過因為本地推送是需要許可的，所以無論怎樣如果你想要依靠通知來提高用戶留存率的話，現在都繞不開用戶許可了。

另外，通知中心加入了非常方便的 Action 特性，用戶可以在收到通知後，在不打開應用的情況下完成一些操作。可以說配合通知中心的 Today 擴展，用戶現在在很可能可以在不打開應用的情況下就獲取到他們想要的信息，並完成互動。這對於開發者可以說是一件喜憂參半的事情，一方面我們可以給用戶提供更好更快的使用體驗，但是另一方面這將降低用戶打開應用的意願。不過 Apple 現在的總體思路還是 app 的體驗才是最重要的，所以正確的道路應該還是優先做好 app 的體驗，並且摸索一個應用和通知之間的平衡點，讓大家都滿意。

 

B、 CoreLocation

 

CoreLocation 室內定位。現在 CL 可以給出在建築物中的樓層定位信息了，直接訪問CLLocation實例的floor，如果當前位置可用的話，會返回一個包含位置信息的非 nil 的CLFloor以標識當前樓層。這個使得定位應用的可能性大大擴展了，想象一下在復雜的地鐵站或者大廈裡迷路的時候，還可以依賴定位系統，幸福感湧上心頭啊。

C、 Touch ID

Touch ID API，說是開放了 Touch ID 的驗證，但是實際上能做的事情還是比較有限。因為現在提供的 API 只能驗證用戶是不是手機主人本人，而不能給出一個識別的標志或者唯一編碼，所以想用 Touch ID 做注冊登陸什麼的話可能還是不太現實。不過在進行支付驗證之類的已登錄後的再次確認操作時就比較好用。現在看來的話這組 API 就是為了簡化像 Paypal 或者支付寶這樣的第三方支付和確認的流程的。希望之後能繼續放開，如果能給一個唯一標識的話，也許就可以干掉整個討厭的注冊和登陸系統了。

D、相機和照片

新增加了 Photos.framework 框架，這個框架用於與系統內置的 Photo 應用進行交互，不僅可以替代原來的 Assets Library 作為照片和視頻的選取，還能與 iCloud 照片流進行交互。除此之外，一個很重要的特性是還可以監聽其他應用對於照片的改變，可以說整個框架非常靈活。