Before the 5.4 questions, one thing about the plan itself, because it may make both of them moot.
To detect adult sites outside Safari, I plan to use a NEPacketTunnelProvider that runs entirely on the device: it inspects the SNI locally
NEPacketTunnelProvider works at the IP layer. It does not receive flow or application-level metadata, which is exactly what content filtering needs — Apple's own guidance on this is blunt: if your goal is to filter content, use the Content Filter API, not a packet tunnel. SNI inspection also stops working the moment Encrypted Client Hello is in play, and that is not a hypothetical any more.
You already hold Family Controls (Distribution), and that is the shorter road. With .individual authorization:
ManagedSettingsStore().webContent.blockedByFilter = .auto()
That applies Apple's own adult-content classifier system-wide — every browser, not just Safari — with no tunnel, no VPN profile, no network extension, and therefore no Guideline 5.4 at all. For a self-control app aimed at exactly this category of site, it is the intended mechanism.
Two things worth knowing before you rely on it. .specific(...) domain lists cap out around 49 entries and blocking silently stops past that — undocumented, and people keep rediscovering it. And if you genuinely need URL-level rather than domain-level decisions, the modern sanctioned path is NEURLFilter (iOS 26, introduced at WWDC25), which is a content filter, not a VPN — different framework, different review conversation.
Now the two questions.
Does the requirement that an app "may only be offered by developers enrolled as an organization" apply to a content blocking app of this kind?
Read literally, no: that sentence is scoped to "apps offering VPN services", and parental control, content blocking and security apps appear in a separate sentence. Read practically, it does not help you, because a NEPacketTunnelProvider installs a VPN configuration and puts the VPN badge in the status bar. To App Review, that is an app offering a VPN, regardless of whether a single packet leaves the device. The "it never routes traffic anywhere" argument is true and largely irrelevant to how the submission is read.
What is an "approved provider" in the sense of Guideline 5.4?
There is no definition, no form, and no entitlement by that name — you are not missing a page. The nearest concrete gate is the Network Extension capability, and since 2016 Packet Tunnel, App Proxy, Content Filter and DNS Proxy are self-serve: you enable them in Xcode, no request. Only Hotspot Helper and the NE app push provider are still requested. So "approved provider" is not a programme you can apply to in advance; it is App Review's judgement at submission, which is precisely the uncertainty you were trying to avoid by asking first.
Which is the strongest argument for the Screen Time route: it removes the question instead of answering it.
