Recommended Architecture for Near-Real-Time Local Device Monitoring in Background

Hello,

We are designing an iOS application for a vehicle safety use case. The app connects to a local network device (a DVR installed in the vehicle) and processes image frames to detect passenger-left-behind items, then alerts the driver if needed.

We would like to better understand the recommended and App Store-compliant architecture for handling this scenario, especially when the app is not in the foreground.

Current Requirements The app communicates with a local network device over Wi-Fi The device can provide image data The app performs or triggers AI inference based on the received data When a relevant event is detected, the app needs to notify the user (e.g., audio alert) Questions

  1. Background Execution Model

For a near-real-time monitoring scenario, what architectural patterns are recommended on iOS when the app is running in the background?

  1. Background Modes Consideration

In this type of use case, are any existing background modes (such as location or external accessory) considered appropriate when used strictly within their intended purpose?

  1. Enterprise / Managed Deployment

Are there any specific entitlements or capabilities available in enterprise or commercial deployments that may allow more persistent local network communication under certain conditions?

The app communicates with a local network device over Wi-Fi. The device can provide image data. The app performs or triggers AI inference based on the received data. When a relevant event is detected, the app needs to notify the user (e.g., audio alert).

We don't currently have any API that supports "Wi-Fi" accessories. If you haven't already, I'd encourage you to file a bug asking for us to better support this, then post the number back here so I can make sure it's routed properly.

For a near-real-time monitoring scenario, what architectural patterns are recommended on iOS when the app is running in the background?

iOS doesn't have a "general purpose" architecture for background execution. There are a variety of use case-specific APIs, each of which defines and controls exactly how and when the app is awake in the background. Some of them will keep an app fully awake while that action/activity is active, but the specifics are determined by the individual API.

In this type of use case, are any existing background modes (such as location or external accessory) considered appropriate when used strictly within their intended purpose?

I'm not sure I understand your question. Several of our categories (notably "location" and "audio") can keep an app awake in the background indefinitely, but what matters is that you're using them for their intended purpose, not the service they provide to your app.

One special comment— despite the relatively generic name, "external-accessory" is NOT a "general purpose" background category. Its only role is to support MFi accessories using the ExternalAccessory framework and, outside of that context, it does absolutely nothing.

Are there any specific entitlements or capabilities available in enterprise or commercial deployments that may allow more persistent local network communication under certain conditions?

No, not really. The closest API would be the Local Push Connectivity extension, but that API is limited to communication apps (VoIP).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Recommended Architecture for Near-Real-Time Local Device Monitoring in Background
 
 
Q