When do you still need a URLSession delegate, and how do the async APIs and per-task delegates fit?

The async methods (data(for:), download, upload, bytes) cover most calls with no delegate. You still need one, at session or task level, for things that are events rather than results: authentication and trust challenges (urlSession(_:didReceive:completionHandler:) for client certificates, basic auth and server-trust evaluation such as pinning, Q317), redirect control (willPerformHTTPRedirection, to refuse or modify a redirect, for example to avoid forwarding credentials), progress (didSendBodyData, didWriteData), metrics (didFinishCollecting), caching decisions (willCacheResponse), background sessions (always) and tasks that must wait for connectivity events (taskIsWaitingForConnectivity).

Two ways to attach one. A session delegate is passed when you create the URLSession and sees every task; the session retains its delegate until invalidated (finishTasksAndInvalidate), which is a classic leak: a session created per screen with self as the delegate keeps the screen alive. A per-task delegate (the delegate: parameter of the async methods) applies to that one task and is retained only for its lifetime, so it is the neat choice for “show progress for this download” and “handle this one auth challenge”. Delegate callbacks arrive on the session’s delegate queue (a serial operation queue), so hop to the right actor before touching state, and always call the completion handler exactly once. Use one shared session per configuration (do not create a session per request: you lose connection reuse).