Background UDP receive for lighting control (Art-Net/sACN)

Question

Created 4d

Replies 1

Boosts 0

Participants 2

I'm developing a lighting control app for iOS that receives Art-Net (UDP port 6454) and sACN (UDP port 5568) packets from a lighting console and relays commands to BLE wristbands with LEDs. This is used in live event production — the participant locks their phone while in a show and expects lighting control to continue uninterrupted.

The problem

UDP receive stops reliably ~30 seconds after the screen locks. I understand this is by design - iOS suspends apps in the background. However, I'm trying to understand if any supported path exists for this use case.

What I've already tried

UIRequiresPersistentWiFi = true - helps with Wi-Fi association but doesn't prevent app suspension
Silent AVAudioEngine loop with UIBackgroundModes: audio - keeps the app alive, works in testing, but risks App Store rejection and feels like an abuse of the audio background mode
NWListener (Network framework) on the UDP port - same suspension behaviour
Socket rebind on applicationWillEnterForeground - recovers after resume but doesn't prevent dropout

What I'm asking

Is there any supported background mode or entitlement for sustained UDP receive in a professional/enterprise context? (Similar to how VoIP apps get the voip background mode for sustained network activity.)
Is the silent audio workaround considered acceptable for App Store distribution in a professional tools context, or will it be rejected?
Is NEAppProxyProvider or another Network Extension a viable path, and if so does it require a special entitlement?

Test project

I have a minimal Xcode project (~130 lines) demonstrating the issue — NWListener on port 6454, packet counter, staleness timer, and silent audio toggle. I can share the test code.

STEPS TO REPRODUCE

In Xcode (one-time setup):

Select the UDPBackgroundTest target → Signing & Capabilities → set your Team
Plug in your iPhone → select it as the run destination
Build & run — confirm packets appear on screen when you run 'send_test_udp.py'
Lock the phone and observe the dropout

Test:

Open the app and run 'python3 send_test_udp.py 192.168.0.XXX'
The app counts up the packages, they match the python output. 1 packet per second.
lock screen & and wait 10 seconds
unlock phone an see the numbers are 10 packets off

Boost

Answer 1

DTS Engineer OP

Apple

3d

Thanks for bringing this to the forums.

Lemme start out by linking to iOS Background Execution Limits. You’ve probably already seen it, but it sets the stage (hey hey) for other folks following this thread.

There are two parts to this:

What’s technically possible?
What will be accepted by App Review?

I can’t addresse the second part. I don’t work for App Review and thus can’t speak on their behalf. My general advice is that you consult their published guidelines and, if you still have questions, contact them directly.

With that out of the way, let’s return to the technical stuff. I want to start by recapping some of the points from TN2277 Networking and Multitasking:

Networking works fine in the background as long as your app doesn’t get suspended.
If your app does get suspended, normal networking will just stop. For things to continue, you need some sort of special affordance, the canonical example of that being a URLSession background session.

There’s no special affordance for UDP. So, your question is equivalent to “How can my app run indefinitely in the background?” And once you phrase things that way, it’s obvious why you’re running into problems )-:

Now I want to address some specific points:

UIRequiresPersistentWiFi

That won’t help, but it brings up a relevant point.

It won’t help because this property only takes an effect when your app is in the foreground, and locking the iPhone moves your app to the background.

It’s relevant because your setup is predicated on the iPhone being on Wi-Fi, and there’s no guarantee that it’ll stay on Wi-Fi once the screen is locked. iOS runs its critical system services over WWAN so, in general, if there’s nothing keeping them on Wi-Fi, they tend to transition to WWAN.

I talk a lot more about this in Extra-ordinary Networking > The iOS Wi-Fi Lifecycle.

Similar to how VoIP apps get the voip background mode for sustained network activity.

That’s not how VoIP apps work, at least not these days. VoIP apps use a combination of:

Push notifications, for ring indication
Audio sessions, which prevents the system from suspending the app while a call is active
CallKit, for managing their user interactions

The voip background mode gates access to some of these. I defer to my colleague Kevin for the deep details, but none of this is relevant to you because you’re not a VoIP app.

The exception here is VoIP apps that are expected to work in an isolated environment, one that’s not connected to the Internet, the canonical example being a cruise ship. Those use an app push provider, which can do networking in the background indefinitely. See Local push connectivity for the details.

However:

This is gated by a managed capability.
And its use case is far removed from yours.

Is NEAppProxyProvider or another Network Extension a viable path

No. Most NE providers won’t work for technical reasons, or will kinda work but with significant caveats [1]. The obvious exception is an app push provider, which won’t work for business reasons, as I’ve explained above.

In summary, I don’t see a good path forward for you. But before I say that definitively, I want to clarify some points about your use case:

You tagged this thread with WatchKit, but didn’t mention the Apple Watch in your post. How does watchOS figure into this?
Is your app typically deployed in managed environments (MDM)? Or do you need a solution for normal, unmanaged devices?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] We see a lot of folks trying to misuse NE providers for all sorts of things. This often doesn’t end well, which is one of the reasons my erstwhile colleague wrote TN3120 Expected use cases for Network Extension packet tunnel providers.

0