Post

Replies

Boosts

Views

Activity

Waking a sibling app in the background to relay data from an ExternalAccessory app (no Internet access available)
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.
1
0
38
4h
Waking a sibling app in the background to relay data from an ExternalAccessory app (no Internet access available)
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.
Replies
1
Boosts
0
Views
38
Activity
4h