我们的应用程序现在使用iOS推送通知的生产证书。
我们经历了几轮推动工作，然后他们就停止了工作。通常，“停止工作”与某些服务器故障相关联。然而，我们使用的服务器说我们仍然起诉我在制作证书时生成的相同p12，但他们从Apple获得了错误代码8，这意味着它是一个无效的令牌。
我重新生成证书，并且“脏”配置文件/标识符重新加载服务器上的p12s，一切正常......一段时间。然后他们只是神奇地开始得到“错误代码8”，我们必须重新开始。
今天我注意到我们的应用程序的上一个版本仍然运行正常但当前版本没有。它们都使用相同的配置文件和/或企业分发配置文件构建，两者都使用相同的应用程序ID证书，两者都加载到TestFlight（仅用于提供信息），并在其中包含相同的推送相关代码。
奇怪的是，当我使用旧的版本时，我得到了一个4xxxxx ...设备令牌（始终是相同的），当我使用新版本时，我一直从Apple取回一个5xxxxx ...设备令牌（始终如一）。
我知道以前的版本之前获得了5xxxx ...设备令牌，因为我在相当一致的基础上检查了它。
但是，我注意到我们的一些测试人员注册了更多的设备令牌，而不是他们说有设备，所以这个问题可能已经持续了很长时间，我错误地认为这是另一个问题。
是什么原因导致设备令牌具有一致但不同的数字？
设备令牌的解剖结构是什么？
有没有人知道为什么完全相同的配置文件/标识符会突然停止工作以获得完全相同的推送证书？
由于
答案 0 :(得分：0)
设备令牌很少改变。我知道要更改的唯一实例是升级iOS版本或从备份恢复设备。因此，对于不同的构建，您为同一设备获取不同的令牌这一事实可能意味着其中一个构建使用沙箱证书而另一个构建使用生产证书。我能想到的唯一其他解释是，为了测试旧版本，您可以从备份中恢复设备，从而更改其设备令牌。
根据您的问题描述，您的数据库似乎包含沙盒设备令牌和生产设备令牌的混合。它们混合不好。沙箱令牌在生产环境中无效，反之亦然。
您应该清除数据库并开始从用户那里收集设备令牌，否则您应该找到导致无效令牌响应的所有令牌并删除它们。
来自Apple的Technical Note：
最常见的问题是设备令牌无效。如果令牌来了 来自沙盒环境，例如当你测试时 开发内置，你不能把它发送到生产推动 服务。每个推送环境都会为其发出不同的令牌 相同的设备或计算机。如果您确实发送了设备令牌错误 在环境中，推送服务会将其视为无效令牌 放弃通知。
注意：建议您运行单独的实例 每个推送环境的提供者，以避免发送问题 设备令牌到错误的环境。