Waking a sibling app in the background to relay data from an ExternalAccessory app (no Internet access available)

Question

Created 20h

Replies 1

Boosts 0

Participants 2

We are developing a system consisting of two iOS apps from the same developer (same Team ID):

・App A acquires data from an external accessory. For regulatory/compliance reasons that we cannot detail here, App A must have no networking capability at all.

・App B is intended to receive data from App A and upload it to a server.

Two important environmental constraints:

・The deployment environment is a closed local network. The server App B talks to is on the local network, and Internet access is not guaranteed. Therefore, any APNs-dependent approach (silent push, etc.) is not viable.

・Latency requirement: near-real-time is ideal, but a delay of up to a few minutes is acceptable.

What we have considered:

1.App Groups shared container — App A can write data, but there is no way to wake App B in the background when new data is written.

2.URL schemes — can launch App B reliably, but bring it to the foreground, which disrupts the user's workflow.

3.BGTaskScheduler — rejected; execution timing is entirely at the system's discretion.

4.Silent push — rejected; requires APNs / Internet connectivity, which we cannot assume (see above).

Our current leading candidate is a combination of (1) and (2): App A writes data to the App Groups container, then opens App B via a URL scheme; App B reads the container and uploads. This works, but the foreground app switch on every hand-off is far from ideal.

We are aware that some apps abuse background modes (e.g., playing silent audio) to stay resident. We assume this violates App Review Guideline 2.5.4 and is not an option for us — please correct us if there is any legitimate variant of this approach.

Questions:

1.Is there any supported mechanism to keep App B running (or reliably woken) in the background, so that it can receive data from App A and upload it — without user interaction and without Internet access?

2.If not, is there any way to mitigate the foreground switch in our current App Groups + URL scheme approach (e.g., returning to App A automatically after the hand-off)? Or would that ping-pong pattern itself be an App Review concern?

Any guidance would be appreciated.

Answer 1

DTS Engineer OP

Apple

1h

Our current leading candidate is a combination of (1) and (2): App A writes data to the App Groups container, then opens App B via a URL scheme; App B reads the container and uploads. This works, but the foreground app switch on every handoff is far from ideal.

With one exception[1], this is the only option I'd consider truly reliable. The biggest issue here is this:

・Latency requirement: near-real-time is ideal, but a delay of up to a few minutes is acceptable.

There are a number of different "tricks" that might make it possible to be "background only" at least some of the time, however:

All of them have some degree of unreliability, so you'd still need a "backup" path that would ultimately require foregrounding the app.
All of them are going to have a typical latency that's better measured in "hours", not "minutes".

[1] The one exception here would be to use external accessory itself. For example, if your accessory had a "Data Collection" and "Data Notify" protocol, then app A could collect the data through the first protocol and have the accessory wake/notify app B through the second protocol. However, this does require hardware-level support/modification and may also have regulatory issues.

We are aware that some apps abuse background modes (e.g., playing silent audio) to stay resident. We assume this violates App Review Guideline 2.5.4 and is not an option for us —

Correct, that it is not a valid use of "audio".

Is there any supported mechanism to keep App B running (or reliably woken) in the background, so that it can receive data from App A and upload it — without user interaction and without Internet access?

We don't really have a mechanism for this (certainly not a general one), as it makes it very easy for multiple apps to keep each other running in the background "forever", something our entire background API strategy is intended to prevent.

If not, is there any way to mitigate the foreground switch in our current App Groups + URL scheme approach (e.g., returning to App A automatically after the hand-off)?

Sure, you can use URL schemes to bounce back and forth between apps.

Or would that ping-pong pattern itself be an App Review concern?

The big issue here is what the overall user experience looks like. At one extreme, if two apps just bounce back and forth without any apparent explanation or reason, then I'd personally hope that app review would raise their hand and say "this seems pretty broken". On the other hand, if your app provides a clear explanation of what's going on and why (progress bars, guidance to the user, etc.), then I don't see any reason why app review would care.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware