Silent Push Notification in iOS 7 does not work

Question

In the WWDC 2013's "What's New with Multitasking" presentation, there is a section about Silent Push Notifications. It seems straight forward. According to the presentation, if you send the APS payload with just the content-available set to 1, users will not be notified of the notification.

// A. This doesn't work
{ 
 aps: { 
 content-available: 1 
 }
}

My testing shows that this does not work as no push is received. But if I include the sound attribute but exclude the alert attribute, it works (though not silent anymore).

// B. This works
{ 
 aps: {
 content-available: 1,
 sound: "default"
 }
}

However, if I change the sound attribute to play a silent audio, I can mimic a silent push.

// C. This works too.
{ 
 aps: {
 content-available: 1,
 sound: "silence.wav"
 }
}

Does anyone know:

1. If this a bug?
2. And if it is correct to assume that B or C is being treated as a Remote Notification (and not a bug with Silent Push where you need a sound attribute)? If so, this means it is not rate limited like Silent Pushes are... which Apple will likely fix. So I probably should not rely on it.
3. What the rate limit is (N pushes every X seconds, etc)?

Edit with more information

For A, the state of the application does not matter. Notification is never received.

It seems like B and C only work if you enclose the attributes and values in quotes, like below.

{"aps":{"content-available": 1, "sound":"silent.wav"}}

And the notification arrives in application:didReceiveRemoteNotification:fetchCompletionHandler: regardless of state.

• DerBernie: Does it not work in any app state? For me, "A" works as long as the app is running in foreground (didReceiveRemoteNotification gets called). But when the app is not running, the app is not getting notified (I just hear the sound, when I try "B"). Does your app get woken up (didReceiveRemoteNotification) in background when you use "B" or "C"?
• nickthedude: I'm seeing similar behavior, im thinking it might be because i've been trying this for a while and i didn't have the app set up correctly at first so Apple may have throttled me before i had the setup correct.
• Michael Wiles: Dude... I wish I could give you 10 votes
• IgniteCoders: Look if you check Background fetch checkbox in Project Capabilities > Background Modes because the first option should work. Silent push doesnt need a sound attribute and always arrives in application:didReceiveRemoteNotification:fetchCompletionHandler: even if the application is running in background / foreground or not running.
• Amit Khetan: It's 2021, I'd been working on my app and meant to use silent push notifications, however wasn't able to receive it until I stumbled on this post. It's weird but having the key "sound" in the payload worked. Thanks for putting this in the community. I hope someone puts a reasonable explanation sometime. Kudos.

Answer 1

This works also and does not play a sound when it arrives:

{
 aps = {
 "content-available" : 1,
 sound : ""
 };
}

EDIT

People having this problem may want to check out this link. I have been participating in a thread on Apple's Developer forum that goes over all app states and when silent pushes are received and not received.

• SG1: Thanks for the link. There are multiple threads discussing this on ADC's Forums. Bottom line: there is a bug - after device restart - which an Apple rep has acknowledged should be fixed in an update (eventually).
• malex: In iOS7 it works great even without sound/alert keys. Content-avalable is sufficient key! But in iOS8 we have really strange behavior when even we set alert key with non-empty string in addition to "content-available" : 1 we get only banner with "alert" string, but "content-available" is ignoring for some reasons
• emem: I have had success with launching the app from notification with or without the added sound. Maybe, setting a sound, alert, or badge (empty or not) rises the default notification priority to 10, thus increasing its reliability. See what Apple says about pans-priority: developer.apple.com/library/ios/documentation/… The default priority is 10 (high), but it is an error to use this for push notification with only content-available key. So maybe the default is set to 5 if only the content-available key is set.
• Stony: doesn't work on iOS10. I must push something to "sound".
• Evan Kirkwood: The link to the Apple Developer Forum thread in the edit seems to be dead. I know this is going back a long time now, but does anyone happen have an updated link (or title of that thread)?

Answer 2

So I just came across this issue yesterday, and after trying sending a payload with a sound set to an empty string, it was still causing vibration/sound on the device. Eventually, I stumbled on a blog post from Urban Airship that suggested needing to send:

{ priority: 5 }

in the push notification, which I had never seen. After perusing Apple's docs for push notifications, I stumbled on this page:

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html

Which indicates that priority should be set as "5" or "10", and explains:

The notification’s priority. Provide one of the following values:

10 The push message is sent immediately.

The push notification must trigger an alert, sound, or badge on the device. It is an error to use this priority for a push that contains only the content-available key.

5 The push message is sent at a time that conserves power on the device receiving it.

Ultimately, we were able to get silent push notifications working with a badge count (and I suspect you could even do the same with an alert) with the following format:

 aps = {
 badge = 7;
 "content-available" = 1;
 priority = 5;
 };

• rjobidon: Great answer Dave! A priority of 5 is allowed while "it is an error to use this priority [10] for a push that contains only the content-available key." developer.apple.com/library/ios/documentation/…
• Foriger: Should be priority included in payload? IMO it is separete one byte in push you send.
• Sandy D.: Priority does not get set in the payload. This gets set in the binary notification.
• Danny Sung: Still seeing this on Xcode 26 / iOS 26 simulator. "badge" and "content-available" seems to be the minimum requirements for me.

Answer 3

I have tried setting an empty string as the alert attribute and it also worked:

{
 aps = {
 "content-available" = 1;
 "alert" = "";
 };
}

It seems like APNS is checking for the existence of this attributes for the purpose of validating the push payload. Interestingly, they are not checking the actual content. It seems a little bit hacky though...

• loretoparisi: This solution with alert="" in the payload worked for me as well on iOS 9.0. The sound="" didn't work instead.

Answer 4

I use the tool-Knuff send my push notification to my device.

It looks like: enter image description here

Then,I tried these example.

They are all work!But you must set the priority 10!

So if you are not use the tool,you also note it.

---

examples:

• no alert,no sound

{
 "aps":{
 "content-available":1,
 }
}

• only alert

{
 "aps":{
 "content-available":1,
 "alert":""
 }
}

• only sound

{
 "aps":{
 "content-available":1,
 "sound":""
 }
}

Answer 5

This works for me:

{ 
 aps: { 
 content-available: 1 
 }
}

Look if you check Background fetch checkbox in Project Capabilities> Background Modes

Answer 6

I'm seeing the same problem. If I send a push with "content-available":1 and no other attributes set, the notification is never received. When I add any other attributes it works perfectly.

As a temporary work around I'm adding the badge attribute as this doesn't alert the user in any way apart from adding the badge to the icon.

Let me know if you've found a better solution.

Answer 7

Priority should be set as one item in binary stream but not in payload json string. Apparently only the latest type 2 format can be used in setting priority as follows:

$token = chr(1) . pack('n', 32) . pack('H*', $deviceToken);
$payload = chr(2) . pack('n', strlen($json)) . $json;
$identifier = chr(3) . pack('n', 4) . pack('N', $notification);
$expiration = chr(4) . pack('n', 4) . pack('N', time()+86400);
$priority = chr(5) . pack('n', 1) . chr($priority);
$frame_data = $token.$payload.$identifier.$expiration.$priority;
$frame_length = strlen(bin2hex($frame_data))/2;
$msg = chr(2) . pack('N', $frame_length) . $frame_data;

Format types (first byte) for remote notification binary message:

0 - simple (old) 1 - enhanced (old) 2 - latest with more parameters (new)

Answer 8

Argh! Also pulling my hair out -- this isn't so much an answer as another example of a payload which DOESN'T work. The didReceiveRemoteNotification method is never called, although if the device is sleeping, the alert text IS displayed.

 {"aps":
 { "alert":"alert!",
 "sound":"default",
 "content-available" : 1},
 "content-id":21482,
 "apt":"1"
}

"apt" is a custom field we use to indicate the notification type.

• evalsyrelec: If the app is in the background, and if you remove the 'alert' attribute, you should receive the callback in application:didReceiveRemoteNotification:fetchCompletionHandler:
• DaNLtR: @mkwon and if I want to see the alert(regular push) while in BG + invoke application:didReceiveRemoteNotification:fetchCompletionHand‌​ler: ? Tnx

Answer 9

Setting 'sound' to 0 worked for me... :)

Answer 10

setting priority to 5 did not work for me, but setting sound or alert to an empty string did cause the notification to be handled as a high priority one

Answer 11

We had the same issue with no Notification being delivered. In our case we were using a silent push to update the badge number. When we set empty strings for alert (body and title) and sound it would work, but if any of the keys were not present it failed. Here is what worked, updating the badge with no sound or alert (log of the resulting userInfo dictionary in didReceiveRemoteNotification)

{
 aps = {
 alert = {
 body = "";
 title = "";
 };
 badge = 103;
 "content-available" = 1;
 sound = "";
 };
}