When Urban Airship receives a push notification destined for an Apple device, we typically pass it along to the Apple Push Notification Service (APNS) and the GCM Service (Google Cloud Messaging) within tens of milliseconds or less.
Our architecture, combined with the volume of push notifications we deliver, makes it is highly unlikely that the cause of delay is within our system. Our series of tubes is only so big, and if messages aren't being passed along in a timely fashion, queues back up and we would take notice.
This article describes likely causes for push notification delays on Apple devices.
Cellular data connectivity to devices is often unreliable
Under ideal circumstances, APNS will maintain a persistent connection to each device. This strategy saves power by avoiding polling, allowing the radio interface more time to sleep. On the device, a daemon (
apsd) maintains the connection to Apple's servers.
If this daemon loses its connection, it will reconnect... eventually. Depending on network conditions,
apsd can take a while to retry and reestablish connectivity. If several notifications were sent while the device was off-line, only the latest one would be delivered.
Networks may restrict access to tcp/5223 (iOS), 5228-5230 (GCM)
iOS devices connect to the APNS service on TCP port 5223. If the local (client-side) network restricts access to this port, push notification delivery will fail.
Android devices connect to the GCM service on TCP ports 5228-5230. Similarly, if the local (client-side) network restricts access to this port, push notification delivery will fail.
This problem is most commonly observed on WiFi provided by employers with restrictive default-deny outbound firewall policies.
WiFi is being used for push notifications
Given the choice between WiFi and 3G, APNS will prefer to use 3G and maintain a persistent connection to the device. However, if 3G is not available, a slightly different strategy is used.
Some older devices with WiFi only will switch to polling the Apple Push Notification service every 15 minutes when the display turns off and the device sleeps to conserve power. (i.e., A persistent connection is not maintained.) Keeping the device on USB power will maintain the connection.
Troubleshooting APNS delivery
Restart all wireless. Turn airplane mode off, then on again, to trigger an
Disable cellular data. Turn on airplane mode to disable all wireless communication, then manually enable WiFi. This will force APNS to use WiFi.
Disable device sleep. Connect the device to power, which will disable sleep and allow for a persistent connection over WiFi.
apsd logging. Apple provides a special APNS debug profile which can be installed on a device to enable verbose diagnostic logging. For more details, see the relevant post in the Apple Developer Forums.
Ensure the app is not foregrounded. Applications, by default, are designed to not display any type of alert/notification if the app is in the foreground.
Ensure OS settings have notifications enabled for the app. Some apps may disable notifications by default, ensure in the OS settings that notifications for the application are enabled.
Make sure you don't have any kind of "Quiet Time" set for the device when you are attempting to test. We have seen some instances where a quiet time was accidentally set during the time of testing.