WebRTC Data Channel for Background File Transfer Without Audio/Video

Thank you for your post. We recommend that you sign up for a session with App Review during the weekly Meet with Apple event. Sign in with your Developer ID and select "Request a one-on-one App Review consultation". A member of the App Review team will help you with your questions regarding the review process and the App Review Guidelines.

To expand on the above, there are two aspect to this:

• What’s technically feasible?
• What’s allowed by App Review?

I don’t work for App Review, so I can’t comment on the latter. If you’d like to discuss that aspect, I recommend that sign up for a session as explained by my colleague above.

On the technical side, you asked:

Is it supported for a WebRTC peer connection using only the data channel … to continue sending data when the app is in the background or locked?

The general rule for networking in the background on iOS is that (almost) everything works like it does in the foreground as long as your app is running. Once your app gets suspended, however, all low-level networking stops [1].

So, your question is equivalent to How can I run indefinitely in the background?, and that’s something I cover in iOS Background Execution Limits.

If you have follow-up questions about the technical side of this, I’m happy to answer them here.

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

[1] Some high-level APIs will continue to work, most notably URLSession background sessions.

Thanks Quinn for the clarification. That helps frame the limits much more clearly.

I have a related follow-up:

• I understand from this thread and the docs on UIApplication.beginBackgroundTask(expirationHandler:) that an app can request a short grace period (typically ~30 seconds) to finish up work before suspension.

• In the context of a WebRTC peer connection (data channel only), would it be technically feasible to use such a background task to allow chunk of data to finish sending during that grace period before the app is suspended? Or does the suspension model terminate low-level networking immediately regardless?

Kind note:- Here only the user has started the Upload/Download when the app is in foreground state.

Also, apart from URLSession background sessions (which I know are supported for uploads/downloads even while suspended), are there any other alternatives for performing reliable background networking when the app is not running in the foreground (for example, via BGProcessingTask or other higher-level APIs), or is URLSession background the only supported mechanism?

Thanks again for the detailed explanation!

Or does the suspension model terminate low-level networking immediately regardless?

No.

Let me reiterate this:

everything works like it does in the foreground as long as your app is running

If a UIApplication background task, or indeed any other subsystem, keeps your app from suspending, networking will work just fine [1].

are there any other alternatives for performing reliable background networking when the app is not running in the foreground

There are two ways to slice this:

• Subsystems that do networking while your app is suspended.
• Subsystems that allow your app to run longer in the background.

In the first case, a URLSession background session is the obvious example of this, but there are others. For example:

• AVAsset has a download mechanism that’s effectively a wrapper around URLSession.
• There’s the Background Assets framework, which offers a number of interesting options.

However, I don’t see either being particularly relevant to your case.

In the second case, there are lots of subsystems that allow your app to run longer in the background. Classic examples of this are:

• Navigation apps, while the user is navigating
• Music streaming apps, while music is streaming
• VoIP apps, which on a call

Those are all tied to specific user scenarios, and thus have App Review consequences, something I specifically call out in iOS Background Execution Limits.

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

[1] Mostly (-: You might notice some edge cases. For example, if the screen is locked the device might eventually get around to turning off Wi-Fi, on the assumption that anything critical will re-establish its connection over WWAN. That’s unlikely to be an issue in the UIApplication background task case, because it doesn’t give you enough execution time to get to that point. You’re more likely to see this in, say, a music streaming app, which can remaining running in the background for hours on end.