作者：Gabriel Theodoropoulos，原文連結，原文日期：2016/01/27
譯者：bestswifter；校對：Channe；定稿：numbbbbb
“推送通知？喔，不！”。是的，這就是我被叫去實現一個 iOS 應用中的推送通知功能時，腦海中閃過的第一念頭，而且我相信你們也曾經有過這樣的想法。這不是因為推送通知很難使用，而是在能夠測試推送一條單獨的通知前有很多步操作需要完成，這些操作步驟最終幾乎把所有開發者弄得暈頭轉向。不過我們再堅持一會兒，從頭開始把事情想明白。
在應用不在執行時，我們經常需要把使用者的注意力吸引過來。正如我們所知道的那樣，這可以通過 通知 實現。作為一名 iOS 開發者，你應該知道 iOS 支援兩種型別的通知：本地通知和推送通知（或者叫遠端通知）。在之前的例子中，通知由應用自己 註冊 並 管理，這種通知很容易實現。事實上，你可以在這裡和這裡找到一些先前介紹本地通知的教程。
推送通知不是由應用自己預先計劃的。它們由另外一個服務（叫做 Provider）觸發，通常情況下是 web 伺服器，這些通知往往同時發往多個裝置。有了推送通知，應用開發者可以在需要的時候給使用者傳送訊息，訊息既可以在隨機的時間點被髮送，也可以按計劃時間傳送，訊息主體可以是預設的或自定義的。維基百科頁面是一份很好的資源，它提供了一些關於蘋果推送通知的基本資訊。
每一個推送通知由 provider 經過一條強制指定的路徑發往一個或多個目標裝置。這條路徑必須經過 Apple Push Notification Servers，或者簡稱 APN servers。實際上，這些伺服器會為推送通知規劃路徑，從而發往正確的裝置。通常情況下，訊息在由 provider 傳送給伺服器的幾秒鐘內，被伺服器投遞給目標裝置。簡而言之，遠端通知的生命週期可以總結如下：
Provider >> APN servers >> 目標裝置
我建議你查閱官方文件，文件中有很多有用的細節，介紹了推送通知的工作原理。
在應用可以收到推送通知之前有幾步配置工作，這些步驟總體上可以被分為兩步：程式設計方面的準備和建立各種證書、描述檔案（provisioning profile）等。程式設計部分很容易，它只是幾段必須新增到專案中的標準程式碼。容易引起混淆的是第二步，這些操作需要在不同的地方被執行，比如 Mac 上的鑰匙串訪問程式，Xcode 專案和 Apple Developer Member Center 網站。
除此以外，遠端通知可以被分為兩種，一種是 沙盒 通知，這種通知可以在開發階段使用，因此它可以用於除錯。另一種是 實時 通知，這意味著它只能在產品釋出階段使用。如果你成功的在應用中接收到了沙盒通知，並且正確的執行了此前提到的各種操作，那麼就可以放心的認為實時推送通知也可以正常使用了。毫無疑問，Apple 為傳送沙盒通知提供了專門的測試伺服器，這並不是由生產環境下的 APN 伺服器負責的。
這篇教程的目的很簡單：我們希望為一個 demo 應用實現推送通知功能，併傳送一些沙盒通知以確保通知推送功能正常執行。希望下次你為應用新增推送通知功能時，這篇教程能幫上你。最重要的是，實現推送通知功能事先需要各種繁瑣的配置，這篇教程可以指引你走出這種困境。
關於 Demo 應用
在正式開始一篇教程之前，我總是會給出一些資訊，介紹將要實現的 demo 應用。我經常會提供一個初始專案，不過這次不會。
要想建立這篇教程的 demo，你只需要在 Xcode 中建立一個新的 iOS 專案就可以了。你不需要額外新增任何內容或控制，因為這個專案並非用來測試應用內的功能，它只是作為一個通知推送的目標。
你可以隨便給專案起個名字，比如我把它命名為 PNDemo。
所以在這一步中，我們建立了一個新的 iOS 專案，我們繼續接下來的步驟。
重要提醒：
在開始講解這篇教程的細節概念之前，我必須說明清楚，基於某些會遇到的情況，我做了一些假設。我們約定：
- 你有一個付費的開發者賬戶，或者至少能夠獲取一個這樣的賬戶。
- 在 Apple Developer Member Center 網站中已經至少有一個 iOS Development Certificate，否則你可以看一看這篇文章，如果你需要使用 Code Signing Request (CSR) 檔案，請閱讀下一部分內容來學習如何建立它。
- 你明白我在這篇文章中所說的推送訊息僅僅是指 Apple 公司的推送訊息。
- 你明白當我說“蘋果開發者網站”時，我其實指的是“Apple Developer Member Center”網站。
- 你知道通知的載荷（payload）是什麼（內容、角標、聲音以及其他資料），並且知道如何處理它們。檢視這篇文章可以複習關於通知的知識。
步驟一：證書籤名請求檔案
既然你已經建立好了 demo 專案，那麼暫時先把它擱置一會兒，準備進行整個流程的第一步。我們的目標是建立一個 Certificate Signing Request (CSR) 檔案，這個檔案稍後將被用於建立推送通知的 SSL 證書。
在這一步中，你需要使用 Mac 上的 鑰匙串訪問 應用。你可以使用 Launchpad 或 Spotlight 來找到並開啟這個應用。如果你不熟悉這個應用，不要無意中刪除任何已有的檔案。
開啟 鑰匙串訪問 應用後，如下圖所示，依次開啟這些選單 鑰匙串訪問 > 證書助理 > 從證書頒發機構請求證書，如下圖所示：
在開啟的視窗中，你必須填寫 User Email Address 和 Common Name。除此以外，還需要選中 Saved to disk 選項，這樣你可以把檔案儲存到磁碟中，這個檔案稍後在蘋果開發者網站上會用到。
點選 Continue ，你可以選擇這個 CSR 檔案的檔名和儲存位置。我把這個教程中建立的所有檔案都儲存在一個新建的資料夾中(資料夾的名字是 PNDemo Files，我希望你也這麼做)，CSR 檔名使用的是預設的檔名。
當你看到一條訊息，提示你的證書請求檔案已經被建立時，點選 完成 按鈕，然後你就…完成了。我們剛剛申請並儲存的這個證書將被用於在蘋果開發者網站上為其他證書籤名。
步驟二： 建立一個 App ID
我們的下一步操作是在蘋果開發者網站上建立一個新的 App ID。這個 App ID 是將你的應用和其他應用區分開來的唯一標誌，它可以幫助 APN 伺服器正確的規劃傳送通知的路徑。實際上，你將會看到我們會把這個 App ID 和其它幾樣東西關聯起來：一個用於推送通知的新證書，一個允許我們在測試裝置上執行應用的描述檔案。
先完成最重要的事，我們前往 Apple Developer Member Center，輸入使用者名稱密碼後登陸。然後點選 Certificates, Identifiers & Profiles 連結，於是你會跳轉到合適的頁面。
進入到新的頁面後，點選 iOS Apps 那一節中的 Identifiers 連結。
你會看到 App IDs 選項是事先就選中的(在左側選單的 Identifiers 目錄中)，在主視窗中列出了所有已存在的 App ID 。我們新建立的 App ID 也會被新增到這個列表中，不過首先得點選右上角的加號按鈕。
現在，我們要為 demo 建立一個新的 App ID，對新手來說，我們需要填寫兩部分內容：
- 新 App ID 的描述介紹。在這個例子中，你輸入的內容並不是很重要，不過最好還是要做到語言清晰，具有實際意義。
- 應用的 Bundle ID，你可以直接從 Xcode 專案中複製並貼上到這裡。
你會發現，在這兩個值之間還有一個需要設定的值，它叫做 App ID Prefix。通常情況下，你不需要修改這裡的預設值，但是如果你確實需要選擇一個不同的字首，也別猶豫。在這篇教程中，我選擇使用預設值。
在這一步中，你要記住一個很重要的細節：實現通知推送功能需要選擇 explicit App ID，因為這個 App ID 必須匹配某個具體的 Bundle ID。在這種情況下，蘋果不允許我們使用通配的 App ID(以星號 * 結尾的 App ID)。無論應用具有怎樣的特點，我個人總是認為使用 explicit App ID 比通配 App ID 更好。這樣會讓你在 App ID 列表中，很清楚的區分開每一個 App ID。
設定好以上內容後，向下滾動網頁到 App Services 區域。在所有提供的服務的底部，勾選 Push Notifications 選項，在你開始下一個操作前務必反覆檢查，確保這個選項確實已經被選中。
接下來，點選 Continue 按鈕並等待確認頁面出現。檢查所有的資訊是否都正確無誤，然後點選 Submit 按鈕提交資訊。如果你檢查到錯誤，可以回退到前面的頁面，修改任何一個有錯的值。
在最後一步中，你會看到 Registration Complete 頁面，只要點選 Done 按鈕即可，你會看到新的 App ID 已經被新增到 App ID 列表中。
步驟三：配置推送通知的 App ID
注意到沒有，儘管此前在建立 App ID 時我們勾選了 Push Notifications 服務，但是它在 Development 和 Distribution 模式下都被標記為 Configurable 而不是 Enabled。這說明我們還需要進行一些額外的操作，將通知推送服務切換到合適的狀態。
在這個教程中，我們不會在生產環境中測試推送任何通知，也就是完全不涉及 Distribution 模式。出於這一點考慮，我們只會配置 Development 模式下的推送通知。不過接下來的操作對於 Distribution 模式下的配置完全適用。在一個實際的應用中，你顯然需要配置 Distribution 模式，否則在應用上架 App Store 後，推送通知的功能就會失效。
現在，我們點選列表中剛剛建立的 App ID，在展開的服務列表中，點選 Edit 按鈕進行下一步操作。
向下滑動到 Push Notifications 一節，你會發現兩個按鈕，分別用於建立開發環境和生產環境下的 SSL 證書。因為我們只關心 Development 模式，所以點選下圖中的第一個按鈕：
“很久”以前通過鑰匙串訪問建立的 Certificate Signing Request 檔案是時候登場亮相了。接下來，我們首先點選 Continue 按鈕。如果你還沒有建立 CSR 檔案，這幾條教程會教你如何建立它。
接下來，點選 Choose File… 按鈕並找到你在第一步中建立的 CSR 檔案。如果你沒有修改檔案的預設名字，那麼你要找的檔案的名字就是 CertificateSigningRequest.certSigningRequest。
最後，點選藍色的 Generate 按鈕，如下圖所示：
棒！你已經成功建立了一個新的證書，它可以在 development（sandbox）模式下推送通知。現在你需要把它下載下來，然後新增到鑰匙串（Mac 上的鑰匙串訪問應用） 中，所以接下來你需要點選 Download 按鈕。
你剛剛下載的檔名是 aps_development.cer。在 Downloads 資料夾中找到它，雙擊開啟這個證書並將它新增到 Keychain Access 的證書列表中。
重要提醒： 雙擊開啟 .cer 檔案並將它新增到鑰匙串訪問中時，請確保它被新增到登入而不是系統或其他鑰匙串中。如果加入的鑰匙串有錯，你只需要把證書拖動到登入鑰匙串中即可。這對下一步操作很重要。
把證書新增到 KeyChain 中後，右鍵點選這個證書，然後選擇 Export “…” 選項
匯出格式要選擇成 .p12 檔案，然後點選 Save 按鈕。
如果你不想設定密碼，可以直接點選 OK 按鈕跳過這一步。如果你設定了密碼，那麼就要記住它或者把它寫在某個地方，否則一旦忘記了密碼，這個檔案也就沒用了。
在這個教程中，我們不會用到這個匯出的檔案。但如果你想在遠端伺服器上(比如 Parse)測試推送通知功能，你就需要在推送第一條通知以前提供 .p12 格式的檔案。所以目前你把這個 .p12 檔案和其他檔案一起儲存著就好。這一步的關鍵在於你能夠意識到開發模式下建立 .p12 檔案的方法同樣適用於生產環境。
步驟四：註冊裝置
首先，我需要說明這一步僅對測試沙盒模式的推送通知有用，在實際的生產環境下不需要這一步。現在，我們去蘋果開發者網站上註冊用於測試的裝置，如果你曾經註冊過裝置，也就是列表中可以找到這個裝置，那麼你可以跳過這一步。
假設你現在是第一次新增裝置，首先你需要將物理裝置與 Mac 連線，然後在 Xcode 中開啟 Window > Devices 選單，在開啟的視窗中列出了所有的物理裝置和模擬器。
在左側選擇你的裝置，你會在主視窗中看到更多細節。注意到其中有一項是 Identifier，它的值是一長串數字和字母，雙擊選中這個值並複製。
現在，返回蘋果開發者網站，點選 Devices 目錄下的 All 選項，所有被註冊過的裝置都顯示在主視窗中。要想新增一個裝置，你需要點選右上角帶有加號（+）圖示的按鈕。
在新開啟的表格中，首先在 Name 文字框中輸入裝置名稱（比如 Gabriel’s iPhone 6S 或 My lovely iPad）。然後把之前複製的裝置的 identifier 填寫在 UUID 文字框中，這一步就完成了。
點選 Continue 按鈕，在下一步中需要確認所以填寫的資訊都準確無誤。搞定以上這些後，點選 Register 按鈕完成註冊。
你可以驗證是否成功的註冊了裝置，只要再次點選 Devices 目錄下的 All 選項，然後逐條查詢你剛剛輸入的裝置名即可。
步驟五：建立開發環境的描述檔案
在蘋果開發者網站上的最後一個任務是為開發環境建立一個描述檔案。它將會用於為應用提供程式碼簽名。注意，在把應用上傳到 iTunes Connect 並使用 TestFlight 或上架 App Store 之前，你需要建立釋出環境的描述檔案（Distribution provisioning profile）。它的使用方法和你將要學到的開發環境的描述檔案的使用方法類似。
在蘋果開發者網頁上，點選 Provisioning Profiles 目錄下的 Development 連結，主視窗中會顯示出所有已存在的描述檔案。稍後，我們新建的描述檔案也會新增到這裡。
你可以通過點選右上角的加號（+）按鈕建立一個新的描述檔案。在新開啟的表格中，點選選擇 iOS App Development選項（第一個選項）。注意，如果你建立的是用於釋出應用的描述檔案，就應該選擇底下第二個區域中的選項（很大可能是 App Store）。
選擇了合適的選項後，點選 Continue 按鈕開始下一步操作。
現在，我們要把這個描述檔案與應用對應的 App ID 關聯起來。你需要在下拉選單中查詢並選擇正確的 App ID。
接下來，你需要把你的 iOS Development certificate 匯入到描述檔案中（假設你至少有一個證書）。如果像下圖所示那樣，有多個證書並且不確定該選擇哪一個，一種簡單的方法是勾選 Select All 選項匯入所有的證書，這一步就完成了。
接下來是選擇將要執行應用的裝置，請確保沒有漏選任何用於測試推送通知的裝置。選擇好後再次點選 Continue 按鈕。
最後一步是為描述檔案檔案命名，將它與其他檔案區分開來。我把它叫做 PNDemo Development Profile，你可以根據自己的喜好隨便起名。
點選 Generate 按鈕並等待下一個頁面出現。當新的描述檔案建立完成後，你就可以下載它了。如下圖所示：
你只需要根據以上這些圖片的指示去操作即可，然後雙擊開啟並安裝剛剛下載的檔案。如果你按照我的方式命名，那麼你的檔名會是 PNDemo_Development_Profile.mobileprovision。
步驟六：配置專案
從這一步開始，我們就和蘋果開發者網站說再見了。把目光轉移到我們的專案上來，這裡我們需要完成兩個任務：
-
首先我們要在專案中開啟推送通知功能，這樣裝置才能接收到通知。雖然這是很基礎，很簡單的一步，但是相信我，很多開發者都會忘記啟用推送通知功能。
-
我們需要正確設定應用的 code signing 和 provisioning profiles。注意，接下來的操作都會在 Development 模式下進行，我們完全不會涉及生產環境。但是這兩者非常類似，所以在應用上線前你可以仿照這裡的步驟完成生產環境下的配置。
在 Xcode 中開啟應用，選擇 Project 導航欄中的專案。請確保你處於 General 標籤下，然後點選 Team 下拉控制元件，選擇正確的 team。
如果你的 Team 列表空空如也，那麼你得前往 Xcode > Preferences… 選單，在 Accounts 標籤下新增一個 Apple ID。你需要輸入正確的使用者名稱和密碼並點選 Add 按鈕完成新增。這一步的細節已經超出了本教程的探討範圍，因此如果你拿不準怎麼做，這個連結中的文章會一步一步指導你。成功新增 Apple ID後，關閉偏好視窗並返回 General 標籤，選擇合適的 Team。
接下來，點選 Capabilities 標籤，找到 Push Notifications 這一節，你只需要開啟開關即可。
正如截圖中的資訊所示，一旦啟用推送通知功能，在 Info.plist 檔案中就會自動新增相應的許可權。
現在開啟 Build Settings 標籤，找到 Code Signing 這一節。展開 Provisioning Profile 欄位，然後點選 Debug 這一行中的 Automatic。在展開的列表中有你的開發者賬戶下所有的描述檔案，你需要選擇你上一步下載並安裝的那一個。
因為我們沒有建立釋出應用時用到的描述檔案，所以我們無需設定 Release 這一行中的值。不過當你在蘋果開發者網站上建立並下載釋出應用時用到的描述檔案後，你需要採取與這裡相同的操作。
你可以在描述檔案欄位上面找到 Code Signing Identity 欄位。如果它沒有展開，你可以點選左側的箭頭展開它。這一步的操作和剛才類似，點選 Debug 欄中的預設值 iOS Developer (或 iPhone Developer)，然後在彈出的列表中選擇合適的身份證明。如下圖所示：
在實際應用中，別忘了在 Release 欄中設定 Distribution 模式下的身份證明。
現在，點選 General 標籤左側的 Target 選項，選擇 Project：
找到 Code Signing 這一節，重複之前的步驟。首先選擇 Debug 模式下的描述檔案，然後設定好正確的 Code Signing Identity。
步驟七：註冊推送通知
到目前為止，專案中的配置都結束了，現在我們需要寫幾行程式碼了。首先，我們讓應用自身向 iOS 系統註冊接收推送通知，並指定我們希望接受的通知的型別（比如角標，聲音或警告資訊）。
事實上，我們會用到上述所有型別的通知，這也是我們的在這一步的切入點。開啟 AppDelegate.swift 檔案，在 application(_:didFinishLaunchingWithOptions:) 方法的 return true 前面新增下面兩行程式碼：
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
// Override point for customization after application launch.
let notificationTypes: UIUserNotificationType = [UIUserNotificationType.Alert, UIUserNotificationType.Badge, UIUserNotificationType.Sound]
let pushNotificationSettings = UIUserNotificationSettings(forTypes: notificationTypes, categories: nil)
return true
}
複製程式碼我們首先指定應用中會用到的通知型別，然後建立一個 UIUserNotificationSettings 型別的物件。我們使用這個物件向系統註冊推送通知。如果出於某些原因，你不想使用上面這個陣列中所有種類的通知，只要刪除掉不想要的即可。
現在，我們將這些可能用到的推送通知的型別告知系統，並且註冊接收推送通知：
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
...
application.registerUserNotificationSettings(pushNotificationSettings)
application.registerForRemoteNotifications()
return true
}
複製程式碼儘管以上幾行程式碼都很重要，但最後一行才是裝置能夠接收推送通知的關鍵。這一部分中新增的四行程式碼是一段標準程式碼，所以你幾乎可以把它們用在你的所有專案中。我是說幾乎，因為總會有需要修改通知型別的時候。
步驟八：代理方法
註冊推送通知是很關鍵的一步，但這只是我們要做的程式設計工作的一半。另外一些與程式設計有關的任務是實現一些代理方法，這樣你的應用才能在接收到通知時做出正確響應。我們一個個看這些方法：
首先，我們要實現 application(_: didRegisterForRemoteNotificationsWithDeviceToken:) 方法。它在應用成功註冊推送通知後呼叫。通常情況下，第二個引數至關重要，它包含了每個裝置獨有的一個 key，我們把這個 key 稱為 device token。在實際使用中，你需要把 device token 傳送給伺服器。這裡的伺服器是推送訊息的最初發起方，它把 device token 和其他必要資訊傳送給 APN 伺服器。這就是為什麼 APN 伺服器能夠知道通知的接收者是哪臺裝置。
Device token 的格式是這樣的：< XXXX XXXX XXXX XXXX XXXX >。通常情況下，在傳送給伺服器之前，你需要對它進行一些格式轉換，比如移除 “<” 和 “>”字元或者移除字串中間的空格。不過最終始終何種格式還是取決於伺服器如何處理 device token。一些服務提供商會為你提供框架，以便你整合並處理推送訊息（如 Parse），如果你打算使用他們的解決方案，那麼框架的使用指南會告訴你如何實現格式轉換。
不管怎麼說，由於我們在本篇教程中不會使用真正的伺服器，你只需要瞭解以上知識並在實際的應用中進行正確操作即可。目前我們只打算把 device token 輸出到控制檯中。我們需要知道它的值，這樣待會兒才能測試推送通知。下面是我們的實現程式碼：
func application(application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData) {
print("DEVICE TOKEN = (deviceToken)")
}
複製程式碼我們不能確保註冊推送通知一定是成功的，這個過程可能因為多種原因而失敗。所以，實現下面這個方法也很重要，在這個方法中我們可以處理註冊失敗的情況：
func application(application: UIApplication, didFailToRegisterForRemoteNotificationsWithError error: NSError) {
print(error)
}
複製程式碼當然，你需要根據應用的邏輯或需求來進行適當的錯誤處理。
正如你所知，當應用不在前臺執行時，推送通知會出現在裝置上。但很多時候，應用會在執行時收到推送通知。在這種情況下，作為一名開發者，你需要用適當的方法處理接收到的通知。在 demo 中，我們只是把收到的資訊輸出到控制檯裡。但在實際的應用中，你絕對不應該這麼做。
下面是對應的代理方法的實現：
func application(application: UIApplication, didReceiveRemoteNotification userInfo: [NSObject : AnyObject]) {
print(userInfo)
}
複製程式碼你還可以根據應用的具體需求，使用更多的代理方法，不過這就不是本文所討論的內容了。UIApplicationDelegate 協議的文件可以參考這個連結，你可以從中找到更多有關遠端通知的方法。考慮到這篇教程的目的是指導你實現推送通知的功能，瞭解以上三個代理方法就足夠了。
步驟九：沙盒模式下推送通知
測試推送通知曾經是一件很麻煩的事，因為這隻有一種解決方案。要麼從頭開始寫一個命令列指令碼，要麼找一份已有的指令碼並根據自己的應用和裝置進行修改。時至今日，這個方案依然行得通，但在 Mac App Store 上已經出現了一些專門用於測試推送通知的應用。沒錯，這就是我們將要使用的方案。
使用 Mac 上的應用來測試推送通知的好處在於，它提供了使用者介面（GUI）給我們填寫必要的資料（比如 device token 或推送通知的證書）。而且這些應用隱藏了“無聊”的程式設計部分，比如連線到 APN 伺服器。實際上，在大多數此類應用中，你只需要指定以下三樣東西：
- 用於接收測試通知的目標裝置的 device token；
- 推送通知證書的儲存路徑；
- 推送通知的載荷（訊息、角標數字和聲音）。
在這個部分中，我會向大家展示兩款應用。不過首先要澄清的是：此舉完全不是為了推廣這些應用。你即將看到的這兩款應用，以及 Mac App Store 上其他同類的應用，在我看來是都是可以簡化工作、節省時間的簡單的工具。基於以上邏輯，我們繼續這篇教程，來看看如何成功的推送第一條通知。
第一個要推薦的應用叫 APN Tester Free，你可以在這裡找到它。這是一個免費下載的應用，藉助這個應用你可以快速的測試推送通知。
如上圖所示，你需要把 device token 複製到 Device Token 文字框中（不帶“<“和”>”字元）。你只要執行一次 demo 就可以很容易地在控制檯中看到 device token。你應該會看到如下圖所示的結果：
首次執行應用時，系統會詢問你是否允許接收遠端通知。顯然，如果你想要測試接收通知就必須選擇允許。
在 Payload 文字框中，你需要填寫推送通知的細節內容。比如你希望接收一條訊息，顯示角標數字並播放預設的聲音，你應該這樣寫：
{"aps":{"alert":"Hello from AppCoda!","badge":1, "sound": "default"}}
複製程式碼若想獲取更多有關通知載荷和所有可設定的值的資訊，請訪問官方文件。
在填寫正確的 Certificate 資訊時，你需要點選 Browse 按鈕，在磁碟中查詢開發模式下的推送通知證書（這顯然是在 Gateway 的值被設定為 Development 時的操作）。提醒你一下，這個證書的名字應該是 aps_development.cer（除非你修改了檔名）。找到證書並匯入到應用中後，你會在控制檯中看到一條訊息，告訴你 .cer 檔案已經被成功的載入了。
設定完以上內容後，你就已經準備就緒，可以推送通知了，你要做的僅僅是點選 Push 按鈕。這時你會在應用的控制檯中看到推送通知被髮送的訊息，如果推送失敗，控制檯中同樣會有紅色的文字提示。
如果你按照教程，一步一步的進行操作並且沒有漏掉任何步驟，那麼你將會收到第一條推送通知
你完全可以反覆傳送通知，這樣你可以看到在裝置鎖屏時、開啟通知中心時、甚至是應用執行時等不同情況下，通知是如何出現的。如果在應用執行時收到通知，你會在 Xcode 的控制檯中看到如下輸出：
除此以外，你還可以自己修改角標數字，開啟或關閉通知的聲音。通過這些嘗試，你可以確保所有的配置都正確無誤。
另一個我打算向你展示的應用是一個叫做 Easy APNs Provider 的程式，你可以在這裡找到它。這是一個免費應用，它有一些額外的選項可供設定，因此你可以嘗試設定推送通知更加高階的功能（比如額外的資料）。
使用這個應用時，首先點選 Add tokens… 按鈕並把 device token 新增到應用中。在彈出的模態檢視中，把 token 複製到第一個文字框中，同時務必確保你已經刪掉了“<“、”>”字元和空格。如果格式有誤，token 就無法被新增到應用中。完成這一步後點選 Add 按鈕，你會看到 device token 已經被新增到視窗的底部。你還可以選擇點選 token 的左側，為它起一個名字，然後點選 Confirm 按鈕完成。
接下來，點選 2. Choose Certificate file按鈕，再次找到 aps_development.cer 檔案並把它匯入到應用中。成功匯入後你會在按鈕的旁邊看到證書檔案的名字。
確保右下方的下拉控制元件中被選中的值是：gateway.sandbox.push.apple.com，然後點選 **3. Connect to：**按鈕。在顯示狀態的文字框中，你會看到應用已經成功的連線上了 APN 伺服器。
現在是時候準備推送通知的載荷了，我們把目光轉移到應用視窗的右上角，選擇你想測試的選項。為了最好的演示通知效果，你可以選擇 Content，badge 和 sound 選項。然後在下面的表格中填寫 title，content 和 badge 的值，這裡的值可以隨意設定。如果你想看到載荷的原始模式（JSON 模式），可以點選 Raw 標籤，否則就使用當前這種更容易處理的模式。
最後，點選 5. Send APN 按鈕來傳送通知，幾秒鐘內你的裝置就會接收到這個通知。
正如我在這一步開始的時候所說，你並非只能選擇以上這兩個工具。你可以去 Mac App Store 中找找其他的軟體，它們或許能夠更好的實現你的需求。
總結
在這篇教程中，我們經歷了很多步驟，執行了許多不同的操作。如果你讀到了這裡，並且成功的在沙盒模式下推送了通知，那麼你完全有理由相信在實際應用中，實時通知推送也會正常工作。你只需要遵循文中列出的操作指南，將它們應用於 Distribution 模式並且補上文中沒有處理的部分即可。舉個例子吧，你需要編輯你的 App ID 並建立釋出應用時用到的 SSL 證書，還需要建立 Distribution 模式下的描述檔案，當然還得在專案的 Build Settings 中使用合適的程式碼簽名。無論如何，我都希望本文能夠幫助你理清思路，弄清楚配置通知推送的步驟，最終幫助你更快的完成任務。下回再見！
本文由 SwiftGG 翻譯組翻譯，已經獲得作者翻譯授權，最新文章請訪問 http://swift.gg。