Note The PF side of this is now covered by TN3165 Packet Filter is not API.
Network Extension (NE) providers let you create products for VPN, content filtering, transparent proxying, and so on. Various Apple platforms support various different provider types. See TN3134 Network Extension provider deployment for the details.
On iOS NE providers are the only game in town. It’s not possible to implement products like this in any other way. On macOS, however, there are a variety of other ad hoc techniques you might use. These include:
-
Packet Filter (PF) aka
pfctl(see its man page) -
A utun interface (see
<net/if_utun.h>) -
Network kernel extensions (NKE), aka KEXTs
People use these techniques for a variety of reasons. For example, you might have a product that predates the NE provider architecture, or you might want to reuse code that you wrote for another platform.
Regardless of the reason, be aware that DTS doesn’t support these ad hoc techniques. If you’re building a product like this for macOS, create an NE provider.
We’ve adopted this policy because, in our experience, these ad hoc techniques tend to be very brittle, and thus are not supportable in the long term. A great example of this is PF. There’s no documented arbitration scheme for PF rules so, as a third-party developer, the rules you install might be incompatible with the rules set up by various macOS features, other third-party developers, the user, or the site admin.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Revision History
-
2028-02-09 Added a link to TN3165.
-
2023-11-23 First posted.