Default URLSession TLS Validation vs. Custom Delegate for Self‑Signed Certificates

Goal: Allow an iOS/macOS app to connect to a backend that uses a self‑signed TLS certificate while ensuring that hostname verification remains intact and the connection is not vulnerable to man‑in‑the‑middle attacks.

Constraint: URLSession’s built‑in validation rejects self‑signed certificates unless the app provides a delegate that evaluates the server’s SecTrust as trusted. Implementing such a delegate gives full control over trust evaluation but requires the developer to manually perform hostname verification and certificate pinning; omitting these steps leaves the connection open to a valid certificate for a different host. Additionally, URLSession caches DNS results using the OS stub resolver with an undocumented TTL, so a change in the server’s IP address is not seen until the session is invalidated.

Uncertainty: There is no documented way to keep the system’s hostname checks while replacing only the trust‑anchor validation for self‑signed certs, forcing a choice between the default validation (which cannot be bypassed) and a custom delegate that must re‑implement hostname checks and pinning.

Which approach provides stronger protection against a man‑in‑the‑middle when the server’s IP address may change due to DNS failover?

How does the opaque DNS cache affect the safety of certificate pinning that relies on a baked‑in public‑key hash?

Is there a method to retain URLSession’s built‑in hostname verification while supplying a custom trust evaluation for self‑signed certificates?