上面的评论是不正确的。应用程序 ID 在捆绑包 ID 之前有一个前缀：
应用程序 ID 由应用程序的捆绑 ID 组成，前缀为
Apple 生成的十个字符的代码。团队管理员必须输入
捆绑包 ID。对于证书，它必须包含特定的捆绑包
ID;您不能使用“通配符”应用程序 ID。
您应该检查您的配置文件，以确保它包含正确的 aps 权利：
验证配置文件中的权利是否为
正确的。为此，请在文本编辑器中打开 .mobileprovision 文件。
文件的内容采用 XML 结构。在权利方面
字典找到 aps-environment 键。为了发展
配置文件，该键的字符串值应该是
发展;对于分发配置文件，字符串值
应该生产.
您应该确保在向生产 APNS 服务器发送推送通知时使用生产设备令牌（在沙箱环境中工作的设备令牌在生产环境中不起作用）。
在将应用程序发布到应用程序商店之前，您应该使用 AdHoc 配置文件对其进行测试。 AdHoc 配置文件适用于生产推送环境。
EDIT :
有关设备令牌的一些引用：
来自本地和推送通知编程指南 http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1 :
请注意生产环境中的设备令牌和
开发（沙盒）环境中的设备令牌不一样
价值。
From 技术说明 TN2265 https://developer.apple.com/library/ios/#technotes/tn2265/_index.html :
处理格式错误的通知
如果推送服务，简单的二进制接口会断开连接
收到在某种程度上不正确的通知。您的提供商
可能会将此视为 EPIPE 或损坏的管道错误，以响应发送
通知。另一方面，增强的二进制接口将
发送错误响应，其中包含有关发生的情况的更多详细信息
断开连接之前的通知有误。确定
您的提供商会正确捕获并处理这些情况。
最常见的问题是无效的设备令牌。如果令牌来了
来自沙箱环境，例如当您测试
内部构建开发，您无法将其发送到生产推送
服务。每个推送环境都会为该推送环境颁发不同的令牌
同一设备或计算机。如果您确实将设备令牌发送到错误的位置
环境中，推送服务会将其视为无效令牌，并且
放弃该通知。
最后，本文 http://redth.info/the-problem-with-apples-push-notification-ser/很好地解释了当某些通知无效时（最常见的原因是无效的设备令牌）如何向 Apple 发送多个通知，可能会导致某些有效通知也无法到达。
