在iOS版本是8.1.2，我发现了一个很奇怪的问题：
我实现了以下方法来处理 appDelegate 中的推送信息
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
如果您的设备未插入，则不会调用此方法。
【问题讨论】：
标签： objective-c apple-push-notifications ios8.1
如果你环顾四周，你会发现其他人认为这是 iOS 7.1 beta 中的错误，在 7.1 发布版本中修复，但它可能与任何 beta、Testflight、特定 8.1.2 版本等无关，就像你在回答中所说的那样。我很确定this 是唯一正确的答案。顺便说一句，我也有同样的问题，但在 8.1.3 中，所以我想它也会再次出现在你身上。
一旦您删除应用程序，重新启动手机并安装应用程序，didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler: 就可以正常调用（这解释了“使用 tesflight！”、“在 7.1.x 中它可以工作！”等），但是如果你因为收到远程通知或者没有按时调用completion handler做太多的计算，系统就不会喜欢你了，想调用的时候再调用，一般是0-30分钟后你的通知已经收到，或者很长（见下面的更新）。对我来说，有时在第一次远程通知之后就已经发生了。当然，除非设备已插入，否则它会更加可靠。
一旦您重新连接（插入）设备，系统可能会调用您的方法，通常最多需要 15 分钟才能被调用，或者如果您在一小时后推送相同的通知，它可能会立即工作，但也不确定。这真的很痛苦，但不要认为它是可以修复的，这是 Apple 创造它的方式。
更新：
最终会被调用。我在 18.13h 发送了一个远程通知，直到第二天 09.41h 才呼叫didReceiveRemoteNotification:fetchCompletionHandler:。因此，就我而言，调用该方法需要 15.5 小时。
就我而言，原因可能是我使用远程通知在后台启动和停止位置跟踪，这很繁重。
【讨论】：
在找到another answer 关于这个问题后，我确认这确实是 iOS 8.1.2 中的一个错误。 我很惊讶在互联网上没有太多关于它的东西。
但是通过我的测试，和provision profile没有关系，使用苹果的TestFlight是不行的。
【讨论】：