Will Safari eventually support the full declarativeNetRequest API?

Question

Goal
To migrate a small Safari extension from the legacy .safariextz format to a Safari Web Extension while keeping user experience continuous.
Constraints
The migration must avoid downtime, so the new extension can coexist with the old one until users update. However, a key API needed for content blocking—declarativeNetRequest—is only partially supported in Safari 17, and its future completeness is unclear. The rule limit (5,000 static rules) is already a bottleneck for complex filter lists.
Unresolved Decision
It is not yet documented whether Safari will implement the full declarativeNetRequest specification as defined by the WebExtensions community, nor when such an implementation might appear.
Questions

Will Safari eventually support the full declarativeNetRequest API?
When can developers expect a complete implementation, if at all?
How will rule limits and partial support impact extensions that rely on large or dynamic filter lists?

Tasadduq Burney · Answer

Direct Answer
Apple has not published any roadmap or commitment to implement the full declarativeNetRequest specification as defined by the WebExtensions community. No public timeline exists for a complete implementation. Safari 17+ supports only a subset: static rules capped at 5,000, with dynamic rule APIs (updateDynamicRules, getDynamicRules) either missing or severely limited compared to Chrome and Firefox.

Current State (Safari 17–18)

Static rules: 5,000 maximum per extension (documented in Safari Web Extensions release notes).
Dynamic rules: Not fully implemented; declarativeNetRequest.updateDynamicRules is absent in current seeds.
Rule conditions/actions: Subset of match fields and action types supported; regex, redirect, and header modification support is incomplete.
Coexistence: Legacy .safariextz content blockers and Safari Web Extensions can run simultaneously, but blocking behavior diverges because the legacy API has no rule-count ceiling.

Impact on Your Migration
If your filter list exceeds 5,000 static rules or requires runtime updates (subscription refreshes, user-custom rules), the current Safari Web Extensions API cannot replicate the legacy experience. Workarounds include:

Splitting rules across multiple extensions (each gets its own 5,000-rule quota).
Offloading heavy filtering to a native app or network proxy via NEFilterProvider.
Serving a trimmed, Safari-specific rule set from your update server.

Recommended Steps

Count your current static rules and identify which require dynamic updates.
Test the exact rule set in the latest Xcode/Safari Technology Preview to confirm which rules load and which are silently dropped.
Check the Safari Web Extensions release notes and WebKit bug tracker for declarativeNetRequest entries per Safari version.
If full parity is a hard requirement, file a WebKit enhancement request and monitor Apple Developer forums.

One Diagnostic Detail Needed
What is the exact static rule count in your production filter list, and do you need runtime rule updates (e.g., user-added exceptions, subscription refreshes without extension updates)? This determines whether the 5,000-rule cap and missing dynamic APIs are hard blockers or manageable constraints.

Will Safari eventually support the full declarativeNetRequest API?

Goal

Constraints

Unresolved Decision

Questions

1 answer

Direct Answer

Current State (Safari 17–18)

Impact on Your Migration

Recommended Steps

One Diagnostic Detail Needed

Your perspective belongs here.

0 question comments