88
votes

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)?

Thanks in advance.

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.

11
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"?DerBernie
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.nickthedude
Dude... I wish I could give you 10 votesMichael Wiles
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.IgniteCoders
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.Amit Khetan

11 Answers

73
votes

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.

30
votes

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;
    };
10
votes

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...

6
votes

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":""
    }
}
4
votes

This works for me:

{ 
  aps: { 
          content-available: 1 
       }
}

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

2
votes

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.

1
votes

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)

0
votes

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.

0
votes

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

0
votes

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

0
votes

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 = "";
    };
}