Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find an alternative to VoIP push when building the app for iOS 13 #2714

Closed
SBiOSoftWhare opened this issue Sep 13, 2019 · 10 comments
Closed
Assignees
Labels

Comments

@SBiOSoftWhare
Copy link
Contributor

TL;DR: When we will build for iOS 13 SDK with Xcode 11 we should find an alternative to VoIP push to wake up the application when she is killed to render encrypted messages in notifications. We should try to use a Notification Service Extension to decrypt an encrypted message before it is displayed and see if it can work decently despite the 30 seconds limit of code execution.

About iOS 13 PushKit restriction

New restriction coming in iOS 13

iOS 13 introduces new requirements, detailed here, which now require VoIP push notifications show a full-screen incoming call interface (via CallKit) that the user must interact upon the reception of each notification.

Note: This restriction applies on iOS 13 only if we build the app for iOS 13 SDK with Xcode 11, we can continue to build the app with Xcode 10 for iOS 12 SDK to get some extra times.

##Several alternative options

APNS regular notification

Sending push notifications using only APNS is not an option as it would mean sending all messages unencrypted in push payload.

APNS silent push notification

We can send a silent push with APNS to wake up the app but as said in Apple documentation but there is following restrictions:

The system treats background notifications as low-priority: you can use them to refresh your app’s content, but the system doesn’t guarantee their delivery. In addition, the system may throttle the delivery of background notifications if the total number becomes excessive. The number of background notifications allowed by the system depends on current conditions, but don’t try to send more than two or
three per hour.

as pointed out here other restrictions:

The downsides are quite annoying for this option:

  • You will only get 30 seconds to run.
  • These notifications must have a apns-priority of 5, which might cause them to be grouped and delivered in bursts, and even throttled or not delivered.
  • If the user force closes the app, it will completely ignore all silent notifications until the user opens the app again.

This kind of notification is not reliable but we can use it to keep the app up to date. We can use it in conjunction with new iOS 13 BackgroundTasks framework to extend the duration of the sync treatment. But the main drawback is that the app should not be killed to make silent push working.

APNS notification using Notification Service Extension

A Notification Service app extension lets you customize the content of a remote notification before it is delivered to the user.

From this article we can find following restrictions:

Firstly, your extension will only be launched for notifications which are configured to show on-screen alerts to the user. This means that any silent notifications (like the ones used to update app badges) will not trigger your extension.

As you can see, when using a notification service extension, you only have a limited amount of time to perform the necessary work. If your extension is taking too long, then it will be stopped by the system, and the notification will be delivered as if you had no extension at all.

With this option we can send a generic message in the notification like "Someone send you a message" and put the event id in the custom keys of the push content. And then try to render the final message from this event id within 30s otherwise it will display the generic message.
The main advantage of using Notification Service Extension is that this is possible to execute arbitrary code in background even if the main application is killed by the user.

Conclusion

VoIP push notifications using PushKit framework was an easy way to wake up the application to execute arbitrary code even when she was killed. But if Apple stay on it's position, an application built with iOS 13 will have to show a full-screen incoming call interface on a VoIP push. This makes impossible to silently execute code in the background using PushKit.

The most serious alternative is to use APNS notification with a Notification Service Extension. With this option we will be able to receive a notification even if the app is killed. But the drawback is that the user could end with a default title and message if the final message could not be rendered in time (within 30s).

@VishalSharma91
Copy link

One question relevant to VoIP push notifications, when I failed to report call kit manager that has stopped delivering even simple push notifications to my app. What shall I do to reset this? There must be some solution to this right?

@ismailgulek
Copy link
Contributor

ismailgulek commented Apr 1, 2020

One question relevant to VoIP push notifications, when I failed to report call kit manager that has stopped delivering even simple push notifications to my app. What shall I do to reset this? There must be some solution to this right?

@VishalSharma91 you can reboot your device or delete the app.

@VishalSharma91
Copy link

VishalSharma91 commented Apr 1, 2020

@ismailgulek Rebooted and re-installed the device. It doesn't even call didRegisterForRemoteNotificationsWithDeviceToken method. I think the CallKitManager malfunctioned push for this app.

@toshanmugaraj
Copy link
Contributor

didRegisterForRemoteNotificationsWithDeviceToken

Yes, didRegisterForRemoteNotificationsWithDeviceToken never called, again

@alexeymilakhin
Copy link

Some problem. System are crashed my app after receiving push.
"Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push callback"

@4omar9
Copy link

4omar9 commented May 19, 2020

Hi guys,
I was trying to use UNNotificationServiceExtension, but it turned out it has a limitation of only 12MB of memory. how are you planning on utilizing that?

@ismailgulek
Copy link
Contributor

Closed with #3268

@myoussef89
Copy link

  • had anyone applied this solution?
  • does it work with no problems?
  • what changes should be made from the server-side and the client-side?

@ismailgulek
Copy link
Contributor

We're testing this internally after #3268 on client side and matrix-org/sygnal#114 on server-side. Tracking issues with https://github.com/vector-im/riot-ios/milestone/33. Anyone can test the implementation with xcode11 branch.

@myoussef89
Copy link

@ismailgulek we tried to test the implementation with xcode 11 branch and Sygnal v0.6.0
we still could not receive any notifications.
we tried the APNS with the certificate, also we tried with firebase gcm ios. the push notification is sent from sygnal service, but nothing is received from the app side.

  • is there any new configuration that should be added to the sygnal service ?
  • could we send a test notification from the sygnal service directly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants