Parse Server 3.9 Silent Push Notification on iOS 13 Not Working

[AliZahr]

Was anyone able to send silent push notifications? I am unable to receive the push although it says SENT, in the dashboard.

Can anyone send a sample code of the payload if you were able to successfully send one?

[davimacedo]

Can you share your current code so we can take a look and try to help you to figure it out? Anyway, I can take a look in this thread as it looks to be a good approach.

[AliZahr]

I am sending this push notification from the dashboard with this JSON:
{
"push_type" : "background",
"content-available" : 1,
"priority" : 5,
"videoCallRelated": true,
"videoCallSessionId": "blabla",
"callRejected": true
}
But I am not receiving the silent push notification

[drdaz]

I'm experiencing a similar issue. And I can see on my device logs that the notification is being delivered with a priority of 10, despite my having set priority to 5 in the data object. This is known to fail in iOS 13.

This same setup (without push-type / pushType and priority) worked fine against iOS 12.

[drdaz]

Yeah something seems wrong here. Here's a snippet from an afterSave method I've got:

    const data = {

        where: installationQuery,
        
        data: {
            'content-available': 1,
            'category': 'MessageCategoryId',
            'messageId': objectId,
            'apns-priority': 5,
            'pushType': 'background'
        }
    }

    Parse.Push.send(data, { useMasterKey: true }).then(function() {
        // Successful Push
        console.log("Push success!")
    }, function(error) {
        // Failed Push
        console.log("Push failed :(")
    })

When one of these notifications is received on the iOS device, this is logged in the console:

default	22:44:09.091864 +0200	SpringBoard	Received incoming message on topic org.example.myApp at priority 10

default	22:44:09.095459 +0200	SpringBoard	[org.example.myApp] Received remote notification request F694-86D3 [ hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Alert]

So both the priority and the push type are wrong. Any ideas what I'm doing wrong here?

EDIT: I was trying previously with the documented 'priority' rather than 'apns-priority'. Same result.

[drdaz]

I've spent most of the day trying to figure out how to debug installed modules in node; I'm an iOS guy usually.

Now that I've got there, the implementation of the new iOS flags seems off.

In node_apn/lib/notification/index.js in the exported headersmethod, where we check for, for example, this.pushType before setting the value on the notification. But the pushType value we set in 'data' is in this.payload.pushType at this point.

It's the same mistake for all the others it seems.

The tests in node-apn seem to test the default values given to the notification at init (like priority===10 and pushType===alert). That's why they pass. EDIT: Just double-checked, this isn't correct. I have no idea why the tests pass.

My notifications have started working again locally by adding .payload in all the appropriate places in that headers method.

I'll create a PR; this seems broken.

[drdaz]

@davimacedo Can you comment? I see you've been active on that repo.

[dplewis]

@drdaz Please check the Push Notification Guide

data: {
            'content-available': 1,
            'category': 'MessageCategoryId',
            'messageId': objectId,
            'apns-priority': 5, // should be priority
            'pushType': 'background' // should be push_type
}

[drdaz]

@dplewis I'm aware what the documentation says. What I posted here was a snippet where I was experimenting.

The documentation is wrong about pushType, and the headers aren't being sent.

[dplewis]

@drdaz @acinader @davimacedo

Edited

Looking at the JS Docs headers like push_time and priority should be in the data field. There are other headers like expiration_time aren't in the data field.

The push adapter doesn't check the data field for headers.

Parse.Push.send({
  channels: [ "Mets" ],
  expiration_time: oneWeekAway, // Header
  push_type: ... // push adapter is expecting this.
  data: {
    alert: "The Mets scored! The game is now tied 1-1.",
    badge: "Increment",
    sound: "cheering.caf",
    title: "Mets Score!",
    push_type: ... // not supported by push adapter, is in documentation
  }
})

Can you try if this works for you?

[dplewis]

I updated my comment. I wrote a failing test here

[drdaz]

I tried this adding push_type: 'background' and priority: 5 in the root of the object like you describe here, and that does seem to work. Although the console output on the device is a little odd; the initial message suggests that the notification is sent at priority 1, but delivered to the app with priority 5:

default	10:56:55.382793 +0200	SpringBoard	Received incoming message on topic org.example.myApp at priority 1
default	10:56:55.386442 +0200	SpringBoard	[org.example.myApp] Received remote notification request CAC9-8138 [ hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Background]
default	10:56:55.386517 +0200	SpringBoard	[org.example.myApp] Deliver push notification CAC9-8138
default	10:56:55.386594 +0200	SpringBoard	[org.example.myApp] Request DUET delivers content-available push notification to application
default	10:56:55.387768 +0200	dasd	Submitted Activity: com.apple.pushLaunch.org.example.myApp:B5AA90 at priority 5 <private>

I don't think that was happening with the mods I made in the other PR.

Just tested it. With the format you describe here, setting priority to a value other than 5 doesn't work. The incoming priority value on the device is always 1, and the notification is always delivered to the app with priority 5 as shown in that log snippet.

Oddly enough, the push_type value seems to get sent just fine.

[drdaz]

@dplewis I've been poking at this, and I think I was mistaken. It's certainly hard to see why the code wouldn't behave as you describe, and even harder to see why it would ignore priority but not push_type.

It looks like the priority the message is delivered to the app with, doesn't necessarily correspond with the arguments we assign. Apple's documentation only mentions priorities 5 and 10. And after some hours experimenting with this, I only see messages being delivered with priorities of 1, 5 and 10.

Certainly my claim that the priority value being set here doesn't make a difference was wrong. Sending a background push with a priority of less than 5 doesn't get delivered to the device at all.

[drdaz]

TL;DR Yeah, that works. Thx. 🙏🏼