Is per-app network blocking possible for a consumer iOS App Store app?

Hi Apple engineers and developers, I am developing a consumer digital-wellbeing app called Ghostie and am trying to determine the correct Apple-supported architecture for its iOS version before continuing implementation. Ghostie's core functionality is to let the user temporarily disconnect selected third-party apps from the Internet while keeping the rest of the device online. For example:

  • WhatsApp: blocked
  • Instagram: blocked
  • Slack: blocked
  • Maps: remains online
  • Banking: remains online
  • Music: remains online

On Android, this is implemented using VpnService with per-app traffic handling. For iOS, I have been researching Network Extension, including:

  • NEFilterDataProvider / NEFilterControlProvider
  • content-filter-provider
  • NETunnelProvider / packet-tunnel-provider
  • per-app VPN configurations

Apple's current documentation appears to indicate restrictions around per-app configurations and content filtering on iOS, including managed/supervised-device requirements in certain cases. My question is specifically about a normal consumer application distributed through the App Store, where the user owns and controls their personal device and Ghostie is not an MDM/enterprise product. Is there currently an Apple-supported API, entitlement, or Network Extension architecture that would allow Ghostie to:

  1. identify selected installed third-party apps;
  2. prevent those selected apps from establishing network connections;
  3. leave all other apps' network connectivity unaffected; and
  4. allow the user to turn this blocking on and off from Ghostie?

If this is not possible for an ordinary consumer App Store application, could an Apple engineer please confirm which specific iOS restriction prevents it and whether there is any alternative supported architecture? I am trying to establish the technically and commercially viable architecture before implementing the iOS version. Thank you!

Answered by DTS Engineer in 910412022

See:

The take-home message from TN3120 is that DTS doesn’t support ‘off label’ use of packet tunnel provider, for example, using a packet tunnel provider to implement a content filter.

TN3134 describes two mechanisms for filtering on unmanaged devices:

  • URL filter provider
  • Content filter provider in the Screen Time case

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

See:

The take-home message from TN3120 is that DTS doesn’t support ‘off label’ use of packet tunnel provider, for example, using a packet tunnel provider to implement a content filter.

TN3134 describes two mechanisms for filtering on unmanaged devices:

  • URL filter provider
  • Content filter provider in the Screen Time case

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

would you recommend investigating the URL Filter Provider or Screen Time content-filter approach described in TN3134?

This is a decision you’ll have to make for yourself. Each mechanism has limitations, and you have to trade off between them. Notably:

  • The content filter Screen Time support is limited to child Apple Accounts.
  • The URL filter mechanism only supports filtering URLs, so it doesn’t affect non-HTTP traffic.
  • Also, if the app doesn’t use Apple’s preferred networking APIs, it has to opt in to URL filtering.

ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

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