Local push for wake up an app

Question

Software_team OP

Created Jul ’24

Replies 1

Boosts 0

Participants 2

Hello,

We a company that deals with alarm systems in hospitals and we would need to manage, for one of our apps, that the application, even if in the background, can be reactivated and brought to the foreground showing the type of alarm received.

We learned of a Dutch company who, they say, thanks to a special agreement with Apple, managed to achieve this using Local Push.

We have already done something similar with Android through Foreground services and we would like to do something similar for iOS too but at the moment we have not succeeded because it seems the OS of mobile devices does not allow it.

Apart from the normal documentation on local push I can't find much other information about it.

Is there anyone at apple who could help me?

Thanks

Answered by DTS Engineer in 794819022

We a company that deals with alarm systems in hospitals and we would need to manage, for one of our apps, that the application, even if in the background, can be reactivated and brought to the foreground showing the type of alarm received.

It's important to be specific about exactly what you're wanting to do here. If you're specifically saying "have an event occur which then causes the app to enter the foreground without any user interaction", then that is simply not possible. One of the fundamental design principles of iOS is that the user MUST be involved in and control app switching. I can't think of ANY exception to that within the entire system and it's certainly not a capability that we provide any API for.

On your comment here:

We learned of a Dutch company who, they say, thanks to a special agreement with Apple, managed to achieve this using Local Push.

Local Push Connectivity provides very specific, narrow functionality. More specifically, it's designed to act as a replacement for PushKit and APNS in specific use cases or environments where those APNS simply cannot function. The canonical example of this is VOIP apps that are designed to operate on cruise ships- the ship has a perfectly functional, high performance WiFi network but, assuming it has internent connectivity at all, that connection is EXTREMELY poor- low reliability, high latency, minimal bandwidth.

Note that because the API is only intended to support a relatively narrow use case, access to the API does require an entitlement that needs to be requested from Apple, using the process described on the APIs entry page.

In terms of how the API actually works, the process is relatively straightforward:

Your app implements an NEAppPushProvider extension that's will connect to your server and maintain a control connection to your server as whenever it's running.
When your main app runs, it uses NEAppPushManager to tell the system what SSIDs you're extension should run on. Note that this information will need to come the app "itself", NOT the system. For example, the system doesn't have any API that will retrieve the SSID of the current Wi-Fi network.
When the system joins one of the SSIDs your app declared, the system will run your NEAppPushProvider extension. The extension can then user local notifications to post messages to the user, reportIncomingCallWithUserInfo to for incoming VOIP calls, or reportPushToTalkMessageWithUserInfo for incoming PTT messages.
Note that the functionality described is DIRECTLY equivalent to what any standard VOIP/PTT app could implement using our existing architecture. Local Push Connectivity is designed to act as a narrow replacement for "standard" architecture, not as a broader/better "replacement".

Making sure this is completely clear, nothing in that architecture will allow an app to bring itself to the foreground. The users interaction with your notification or CallKit call could bring your app into the foreground, but that's because of the functionality those APIs always provide, not because of Local Push Connectivity.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’24

Accepted Answer

Recommended

We a company that deals with alarm systems in hospitals and we would need to manage, for one of our apps, that the application, even if in the background, can be reactivated and brought to the foreground showing the type of alarm received.

It's important to be specific about exactly what you're wanting to do here. If you're specifically saying "have an event occur which then causes the app to enter the foreground without any user interaction", then that is simply not possible. One of the fundamental design principles of iOS is that the user MUST be involved in and control app switching. I can't think of ANY exception to that within the entire system and it's certainly not a capability that we provide any API for.

On your comment here:

We learned of a Dutch company who, they say, thanks to a special agreement with Apple, managed to achieve this using Local Push.

Local Push Connectivity provides very specific, narrow functionality. More specifically, it's designed to act as a replacement for PushKit and APNS in specific use cases or environments where those APNS simply cannot function. The canonical example of this is VOIP apps that are designed to operate on cruise ships- the ship has a perfectly functional, high performance WiFi network but, assuming it has internent connectivity at all, that connection is EXTREMELY poor- low reliability, high latency, minimal bandwidth.

Note that because the API is only intended to support a relatively narrow use case, access to the API does require an entitlement that needs to be requested from Apple, using the process described on the APIs entry page.

In terms of how the API actually works, the process is relatively straightforward:

Your app implements an NEAppPushProvider extension that's will connect to your server and maintain a control connection to your server as whenever it's running.
When your main app runs, it uses NEAppPushManager to tell the system what SSIDs you're extension should run on. Note that this information will need to come the app "itself", NOT the system. For example, the system doesn't have any API that will retrieve the SSID of the current Wi-Fi network.
When the system joins one of the SSIDs your app declared, the system will run your NEAppPushProvider extension. The extension can then user local notifications to post messages to the user, reportIncomingCallWithUserInfo to for incoming VOIP calls, or reportPushToTalkMessageWithUserInfo for incoming PTT messages.
Note that the functionality described is DIRECTLY equivalent to what any standard VOIP/PTT app could implement using our existing architecture. Local Push Connectivity is designed to act as a narrow replacement for "standard" architecture, not as a broader/better "replacement".

Making sure this is completely clear, nothing in that architecture will allow an app to bring itself to the foreground. The users interaction with your notification or CallKit call could bring your app into the foreground, but that's because of the functionality those APIs always provide, not because of Local Push Connectivity.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0