Capacitor Web View Networking vs Native HTTP Client: DNS & TLS Interoperability

Goal

Investigate how DNS resolution and TLS certificate validation behave when Capacitor HTTP requests are routed through the embedded Web View versus a native HTTP client, and determine the impact on app reliability when system DNS or certificate stores change.

Constraints & Uncertainty

• Capacitor’s default HTTP plugin uses the Web View’s networking stack, which caches DNS and uses the Web View’s trust store.
• System DNS changes (e.g., VPN, private DNS) may not be reflected until the Web View process restarts.
• There is no exposed API for custom certificate pinning or disabling validation in the Web View stack.

Unresolved Decision

Should Capacitor expose a separate native networking module that bypasses the Web View to provide deterministic DNS resolution and customizable TLS handling, or should it continue to route all HTTP traffic through the Web View for API compatibility?

Specific Questions

1. In what scenarios does the Web View’s DNS cache cause requests to resolve to stale IP addresses, and how long does the cache persist after system DNS updates?
2. Does the Web View’s trust store automatically pick up newly installed root CAs, and does it allow certificate pinning or custom trust policies?
3. What are the trade-offs, in terms of performance, security, and developer ergonomics, between using the Web View stack versus a native HTTP client for Capacitor applications?