Onesignal-ios-sdk: Notification Service Extension is not being called

[animeshp]

Description:
Notification Service Extension is not being called when I run the main app target using Xcode. But when I explicitly run the extension target everything seems to be working fine and my remote notifications are being modified as they should.

Environment

Using Xcode 10.1 and running iOS 12.1 on my device.

Used CocoaPods to install OneSignal using command pod 'OneSignal', '>= 2.6.2', '< 3.0'

Steps to Reproduce Issue:

1. Did everything as listed in the OneSignal iOS setup guide.
2. Run the main app target on device and send push notification using OneSignal dashboard. Notification doesn't get modified.
3. Now, run the notification extension on the device and then send push notification. Notification gets modified.

Anything else:
Do I need to turn on some setting in OneSignal SDK to receive modified notifications when I run the main app target using Xcode?

[Nightsd01]

@animeshp The notification service extension only runs if content_available is set to true in the APNS notification payload. Are you creating these notifications in our dashboard? If so, please make sure you are setting content_available to true.

[animeshp]

So do you mean I need to set content_available to true to invoke notification service extension when I run the main app target from Xcode to my device?

Because my notification service extension is easily invoked without setting content_available when I explicitly run the extension target from Xcode.

[Nightsd01]

@animeshp Our SDK has zero control over whether or not the extension service gets launched. iOS launches it. And iOS will only launch the extension service if content_available is set to true in the push notification.

[animeshp]

BTW it is the mutable-content flag that needs to be set to true rather than content-available flag to activate notification service extension.

I guess you didn't understand my question fully. Anyway I'll try to figure out in some other way. You seem to be in too much hurry to close the issue.

Thanks :)

[Nightsd01]

My apologies that’s correct, it’s the mutable-content flag.

[rajatdew]

@animeshp Did you found the reason and any solution for this? I am facing the sam issue.

[Surya092]

@animeshp It seems it is supposed to work in that manner. When we run the app, push data with mutable Content flag set is treated as Simple Push rather than any call made to extension. However the bundled binary file works fine.

[iZooto-sdk]

NotificationExtensServices not working

Xcode version 11.3
Target version 10.3
ServieExtesnion target :10.3
my Payload

"notification" : {
"body" : "New announcement assigned Data",
"OrganizationId":"2",
"content_available" : true,
"mutable-content": true,
"priority" : "high",
"subtitle":"Elementary School Amit"
},
"data" : {
"priority" : "high",
"sound":"app_sound.wav",
"content_available" : true,
"mutable-content": true,
"bodyText" : "New Announcement assigned Data",
"organization" :"Elementary school Data"
}

[prohoney]

I'm 100% certain this was mentioned in the WWDC. I'll have to find it but the gist of it is:

You should either set content-available to true OR mutable-content to true

You should NOT set them BOTH. It would confuse the OS. The OS wouldn't know whether it should pass the notification to the OS or to the Notification Service Extension.

[chad171]

I don't think this is a OneSignal issue, but it would be great to get some guidance from OneSignal on it. It makes it very difficult to debug service extensions. In effect if I press play on the extension I get the rich messages and can alter the content but can't debug the main app. If I press play on the main app the extension is entirely ignored by the OS (no rich content whatsoever). content-available and/or mutable-content have no affect on this issue.

[prohoney]

@chad171 not sure if this helps but:

If I press play on the main app the extension is entirely ignored by the OS (no rich content whatsoever). content-available and/or mutable-content have no affect on this issue.

Go to Xcode >> Debug >> Attach to process >> Then just select your appExtension target

Also:

If you're trying to debug an extension that is trigged by the OS then you need to do something so that the OS triggers it. Only then you can attach it to the debugger. Example: If you're trying to debug the 'Notification Service Extension' then you'd only see it among the list of targets after you've connected your iPhone to your Mac and have a push notification sent to open the service extension.

From here

[chad171]

Thanks @prohoney
The real issue is that I can't seem to get the ad hoc build of the app to ever trigger the extension on test user devices.

Debug >> Attach to process (before or after receiving a message) does not work as my extension does not show up as an option. I can Debug >> Attach by name >> give the name of the extension. Then after quite a while Xcode says 'waiting to debug'. When I send a push the Xcode Debugger starts with an error message 'Thread 1: EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=24 MB, unused=0x0)'.
If I set the extension as the primary scheme I can debug the extension, and also attach to the main process at the same time. That whole process is fine for development and debugging, however it does not explain why the extension does not load on test devices with an ad hoc build. Or why the extension does not load when I run as the main app as the selected scheme (I assume this is the intended way to develop even though I've never seen it work).

[prohoney]

@chad171
About:

The real issue is that I can't seem to get the ad hoc build of the app to ever trigger the extension on test user devices.
I'd like to know how have you inferred that?

Have you tried putting a log statement in your didReceive callback and see if it gets called.
But if you've already done such and nothing is getting logged then I can think of:

I can think of three things:

• Does your ad hoc build use a different bundle ID? Does your appex match the bundleId accordingly?

e.g. your main app's debug bundle id is:

com.amazon.prime.debug, then it service extension should be named: com.amazon.prime.debug.serviceExtension
while if your adhoc build is:
com.amazon.prime.adhoc, then it service extension should be named: com.amazon.prime.adhoc.serviceExtension

• And then you should also for the ad hoc build you should have the appropriate provisioning profiles for your appex. Is that correctly setup as well? Each bundle id would need a different provisioning profile.

• What iOS version do your test devices have? Note that the minimum deployment version of the appex should be lesser than the iOS version of your test device. Otherwise it just won't ever be built on the test device. And you won't even know about it. Basically if you've set the minimum deployment version to iOS14 but your test device is on iOS13 then the appex won't be built into the device. And you wouldn't knot anything about it.

[chad171]

@prohoney
Thanks again, it's good to hear from someone who has had success building app extensions. I've answered your questions below, and am currently deciphering the console log for the device. Quite a bit of the log mentions my extension so its clear the OS is aware fo the extension at least.

The appex bundle is an extension of the main bundle name.
the didReceive method in the main bundle always gets called.
the didReceive method in the extension is only called when I set the extension as the main scheme. Once I have set the extension as the main scheme and hit run, future push messages go through the extension even if I am not debugging.
I was able to test that the extension is working or not by fully replacing the contents of the push with hard coded values inside the didReceive method rather than observing log messages.
The bundle and appex are set to deployment iOS 10, and all devices are iOS 14.
When doing the ad hoc build I have to specify my provisioning profiles, and Xcode doesn't complain. So I assume its done correctly. All the names look like they are matching in the member centre.
Whats also interesting is that if I show package on the built app, I can see the extension in the plugins folder. So its not like its not being built.

[prohoney]

@chad171 I'm confused as to what your response is. Can you just clarify:

Did the didReceive get called for the adhoc build?

[chad171]

@prohoney
there are didReceive methods in the main app and the appex. In the adhoc build didReceive is not called on the appex.

[prohoney]

@chad171 At this point I recommend you to open a question on stackoverflow. Add your setup info...

[AwaisFayyaz]

I'm 100% certain this was mentioned in the WWDC. I'll have to find it but the gist of it is:

You should either set content-available to true OR mutable-content to true

You should NOT set them BOTH. It would confuse the OS. The OS wouldn't know whether it should pass the notification to the OS or to the Notification Service Extension.

Hi, do we have any references on this ?

[prohoney]

See https://developer.apple.com/videos/play/wwdc2017/708/?time=1358
This is the closest thing I found. But you shouldn't really be looking for a reference. From the pure architectural point of view, it shouldn't work with both.

• silent notifications are notifications that aren't meant to be seen by user
• rich notifications are notifications that are meant to be seen

I don't know what the OS does when it gets both. But whatever it does is undefined and can be changed at any moment. You shouldn't rely on it

@AwaisFayyaz

It's also important to note the notification that can be handled by the service extension are UI notification and they will be presented.

And these are different from silent notifications.

What I mean by that is when APNS delivers the notification to your device, the service extension has the opportunity to intercept it, as we just saw.

Any and all work done in the service extension should pertain to this incoming notification.

There should be no additional background work for your application that should be done here.

All work should be either about modifying or enhancing this notification.

The service extension also doesn't have the power to drop this notification or prevent it from being displayed.

This notification will get delivered to the device.

If instead you want to launch your application in the background and run some additional processing, you should send a silent notification.

You can also send a silent notification and launch your app in the background and your app can determine whether or not to schedule a local notification if you want to present a conditional notification.

The idea is: the OS upon receiving the notification should decide whether it should handle the notification to the service extension or to the main app. Inherent with a silent notification is not displaying. It's really at crossroads.

[AwaisFayyaz]

Thanks for the reply @prohoney. i will check the relevant video