在AdHoc發佈版上使用沙箱APNS iOS版

我一直在閱讀一堆蘋果文檔以及許多其他SO問題，但還沒有找到這個特定問題的答案。在AdHoc發佈版上使用沙箱APNS iOS版

我有一個現有的工作流程來爲QA成員和beta測試人員生成AdHoc分佈版本。現在我已經添加了對推送通知的支持，我希望能夠對這些通知路徑進行測試。

我的印象是，開發人員構建，使用開發配置文件進行簽名，爲沙箱/開發APNS環境生成令牌，並使用分發配置文件簽署分發版本（無論是用於AdHoc分發或AppStore分發），爲生產APNS環境生成令牌。我相信這可以通過打開不同的.mobileprovision文件並檢查密鑰來確認。

我想知道是否有辦法讓我的AdHoc Distribution構建使用沙盒APNS環境，而不是生產APNS環境。

如果我真的想讓QA和beta測試人員使用沙箱APNS，我是否會想方設法讓他們運行開發構建，而不是分發構建？

或者是我對事物工作方式的假設？（參考this post和this post）

來源

2013-03-06 beno

更多關於我的組織的棒球理由......有一個API層抽象出一些通知職責，在許多其他服務中，它有2個「模式」（分段/生產），所以在將內部「分段」API與沙箱APNS環境相關聯時，這是有意義的，但這可能是不必要的區分。 – beno 2013-03-06 15:08:00

我也發現了一些提及到的AdHoc在APNS環境的上下文：

注：還有就是推送服務一個單獨的持久連接爲每個環境。操作系統爲開發構建建立了一個持久的連接到沙箱環境;特設和分銷版本連接到生產環境。

它取自Technical Note TN2265。我猜這個筆記證實你不能在AdHoc發行版中使用沙箱環境。

來源

2013-03-06 16:18:30 Eran

不錯的發現，我沒有看到任何地方明確指出。 – beno 2013-03-06 16:19:46

也發現了這個答案：http://stackoverflow.com/questions/2625773/why-not-use-development-provisioning-instead-of-ad-hoc – beno 2013-03-06 18:02:41

這就是對的。對於GCM，只需轉到AppDelegate.swift，找到方法didRegisterForRemoteNotificationsWithDeviceToken，並用kGGLInstanceIDAPNSServerTypeSandboxOption替換爲kGGLInstanceIDAPNSServerTypeSandboxOption：true：false。之後，你不再處於沙箱環境中。 – stakahop 2016-05-31 09:51:44

蘋果使用了不同的服務器：

應用與發展概況
所有其他配置文件（即席，室內和AppStore的）簽署。這些將通過Live Server進行。

來源

2013-08-30 09:20:15 thatzprem

在AdHoc發佈版上使用沙箱APNS iOS版

回答

相關問題