iOS7、iOS8的新特性

一、iOS7 SDK新特性

1、UI相关

  

简单总结来说，以现在上手体验看来新的UI变化改进有如下几点：

• 状态栏，导航栏和应用实际展示内容不再界限：系统自带的应用都不再区分状态栏和navigation bar，而是用统一的颜色力求简洁。这也算是一种趋势。
• BarItem的按钮全部文字化：这点做的相当坚决，所有的导航和工具条按钮都取消了拟物化，趋于扁平化设计。原来的文字（比如“Edit”，“Done”之类）改为了简单的文字，原来的图标（比如新建或者删除）也做了简化。

  所谓“扁平化设计”指的是抛弃渐变、阴影、高光等拟物视觉效果，从而打造出一种看上去更“平”的界面。也就是说，扁平化设计是与拟物化（Skeuomorphism）设计相对的一个设计理念。扁平化设计最好的理解是“极简”，即强调运用最轻量、简单的设计来传递核心信息，强调通过对视觉焦点的引导来让用户快速地完成操作。

• 程序打开加入了动画：从主界面到图标所在位置的一个放大，同时显示应用的载入界面。

• UIKit的力学模型（UIKit Dynamics

  UIKit动力学 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、游戏方面

  SpriteKit入门 WWDC2013笔记 SpriteKit快速入门和新时代iOS游戏开发指南 http://onevcat.com/2013/06/sprite-kit-start/
  

  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 照片流进行交互。除此之外，一个很重要的特性是还可以监听其他应用对于照片的改变，可以说整个框架非常灵活。