ios 苹果推送通知在生产中不起作用

apple push notification not working in production

提问by Hetfield Joe

We are totally stucked, please help.

我们完全被困住了，请帮忙。

I and my team made a iPhone application, and this is the first time we try on iOS.

我和我的团队制作了一个 iPhone 应用程序，这是我们第一次在 iOS 上尝试。

Everything is fine, until we submitted our app and became available on app-store -- the push notification service is not working. I searched around the web and tried double check on our app by people's advices, but I couldn't find what's wrong. so this question is posted here.

一切都很好，直到我们提交了我们的应用程序并在应用程序商店中可用 - 推送通知服务不起作用。我在网上搜索并尝试根据人们的建议仔细检查我们的应用程序，但我找不到问题所在。所以这个问题发布在这里。

These are what we did:

这些是我们所做的：

1. We build the application, suppose it's named "AppMaster".

2. We created AppId on iOS Provisioning Portal called: "pushtest". This ID enabled the Push Notification on both development and production.

3. We created a Provisioning for development named "AppMasterPushTest" from the appId above. This provisioning is for inside test, everyone of the team installed it on their mac.

4. Our server is implemented by Java and we used the java-apn package. during the test, We downloaded the certification file for development and write out the .p12 file, and pushed our message to the "sandbox" server by using the package's api -- withSandboxDestination() with that .p12 file. test goes fine, notifications are received.

5. I thought we were ready, so we created another AppId called "AppMaster", and enable Push Notification only for production. This Id is written in the app's bundle identifier.

6. We made another Provisioning for production named "appMaster" from AppId in step 5, with distribution method set as "App Store". downloaded it and rebuild app. This one was submitted to apple, and goes alive on app-stroe.

7. Server side, We downloaded the certification for production and write out the .p12 file again. and made program to push message to production server by using the api -- withProductionDestination(), with the .p12 just been write out.

8. We installed the app from App Store. sadly, the notification was never delivered.

1. 我们构建应用程序，假设它被命名为“AppMaster”。

2. 我们在名为“pushtest”的 iOS 配置门户上创建了 AppId。此 ID 在开发和生产中都启用了推送通知。

3. 我们从上面的 appId 创建了一个名为“AppMasterPushTest”的开发配置。此配置用于内部测试，团队中的每个人都在他们的 Mac 上安装了它。

4. 我们的服务器是由 Java 实现的，我们使用了 java-apn 包。在测试过程中，我们下载了用于开发的认证文件并写出了 .p12 文件，并通过使用包的 api -- withSandboxDestination() 和该 .p12 文件将我们的消息推送到“沙箱”服务器。测试顺利，收到通知。

5. 我以为我们已经准备好了，所以我们创建了另一个名为“AppMaster”的 AppId，并且只为生产启用推送通知。此 ID 写在应用程序的包标识符中。

6. 我们在步骤 5 中从 AppId 为生产创建了另一个名为“appMaster”的 Provisioning，分发方法设置为“App Store”。下载它并重建应用程序。这个被提交给了苹果，并在 app-stroe 上活跃起来。

7. 服务器端，我们下载了生产认证，重新写出.p12文件。并使用api-withProductionDestination()制作了将消息推送到生产服务器的程序，.p12刚刚写出来。

8. 我们从 App Store 安装了该应用程序。遗憾的是，通知从未送达。

Is there something we missed? BTW, the id we created in step5 was looks like "XXX.com.company.appname", but in the app's bundle identifier, we just set "com.company.appname" part without prefix. is this could be the problem?

有什么我们错过了吗？顺便说一句，我们在 step5 中创建的 id 看起来像“XXX.com.company.appname”，但是在应用程序的包标识符中，我们只设置了“com.company.appname”部分而没有前缀。这可能是问题吗？

any idea is welcomed.

欢迎任何想法。

please be our saver. thanks.

请成为我们的救星。谢谢。

回答by Eran

The comment above is incorrect. The app ID has a prefix before the bundle ID :

上面的评论是不正确的。应用 ID 在捆绑 ID 之前有一个前缀：

An application ID consists of an application's bundle ID prefixed with a ten-character code generated by Apple. The team admin must enter the bundle ID. For a certificate, it must incorporate a specific bundle ID; you cannot use a “wildcard” application ID.

应用程序 ID 由应用程序的捆绑 ID 组成，其前缀是由 Apple 生成的十个字符的代码。团队管理员必须输入捆绑 ID。对于证书，它必须包含特定的捆绑 ID；您不能使用“通配符”应用程序 ID。

You should check your provisioning profile, to make sure it contains the correct aps entitlement :

您应该检查您的配置文件，以确保它包含正确的 aps 权利：

Verify that the entitlements in the provisioning-profile file are correct. To do this, open the .mobileprovision file in a text editor. The contents of the file are structured in XML. In the Entitlements dictionary locate the aps-environment key. For a development provisioning profile, the string value of this key should be development; for a distribution provisioning profile, the string value should be production.

验证provisioning-profile 文件中的权利是否正确。为此，请在文本编辑器中打开 .mobileprovision 文件。文件的内容以 XML 结构化。在权利字典中找到 aps-environment 键。对于开发配置文件，此键的字符串值应为 development；对于分发配置文件，字符串值应为production。

You should make sure you are using production device tokens when sending push notifications to the production APNS server (device tokens that works in the sandbox environment don't work in the production env).

在向生产 APNS 服务器发送推送通知时，您应该确保使用生产设备令牌（在沙盒环境中工作的设备令牌在生产环境中不起作用）。

You should have tested your app with an AdHoc provisioning profile prior to releasing it to the app store. The AdHoc profile works with the production push environment.

在将应用发布到应用商店之前，您应该已经使用 AdHoc 配置文件对其进行了测试。AdHoc 配置文件适用于生产推送环境。

EDIT :

编辑 ：

Some quotes regarding device tokens :

关于设备令牌的一些引用：

From the Local and Push Notification Programming Guide:

来自本地和推送通知编程指南：

Take note that the device token in the production environment and the device token in the development (sandbox) environment are not the same value.

请注意，生产环境中的设备令牌和开发（沙箱）环境中的设备令牌不是同一个值。

From Technical Note TN2265:

来自技术说明 TN2265：

Handling Malformed Notifications

The simple binary interface drops the connection if the push service receives a notification that is incorrect in some way. Your provider may see this as an EPIPE or broken pipe error in response to sending a notification. On the other hand, the enhanced binary interface will send an error response with more detailed information about what was wrong with the notification before dropping the connection. Be sure your provider catches and handles these conditions properly.

The most common problem is an invalid device token. If the token came from the sandbox environment, such as when you are testing a development build in house, you can't send it to the production push service. Each push environment will issue a different token for the same device or computer. If you do send a device token to the wrong environment, the push service will see that as an invalid token and discard the notification.

处理格式错误的通知

如果推送服务收到以某种方式不正确的通知，简单的二进制接口将断开连接。您的提供商可能会将此视为 EPIPE 或管道损坏错误以响应发送通知。另一方面，增强的二进制接口将发送一个错误响应，其中包含有关在断开连接之前通知出了什么问题的更详细信息。确保您的提供者能够正确捕捉并处理这些情况。

最常见的问题是无效的设备令牌。如果令牌来自沙盒环境，例如在内部测试开发构建时，则无法将其发送到生产推送服务。每个推送环境都会为同一设备或计算机发出不同的令牌。如果您确实将设备令牌发送到错误的环境，推送服务会将其视为无效令牌并丢弃通知。

Finally, this articlehas a good explanation of how sending multiple notifications to Apple when some of the notifications are invalid (the most common cause being invalid device tokens), can cause some of the valid notifications not to arrive as well.

最后，本文很好地解释了如何在某些通知无效（最常见的原因是设备令牌无效）时向 Apple 发送多个通知，也会导致某些有效通知无法到达。