TN3151: Choosing the right networking API

Learn which networking API is best for you.

View Technote TN3151 >

Post not yet marked as solved Up vote post of Jason Down vote post of Jason
1.3k views

Replies

@Jason This Technote is awesome. Is there any explanation of this recommendation?

Unless you have a specific reason to use URLSession, use Network framework for new WebSocket code.

That seems like the opposite of what I would expect, so I'm curious to understand why we should prefer Network framework over URLSession for websockets.

Is there any explanation of this recommendation?

This came up during review but I didn’t include it in the technote because Apple docs tend to focus on the what and how, not the why. But I’m happy to get into the details here on DevForums.

There are four reasons for this:

  • URLSession is very much focused on HTTP, and WebSocket isn’t an HTTP-like protocol. While it uses HTTP under the covers, the actual WebSocket protocol is a reliably bidirectional connection with message framing. Those semantics are a much better match for NWConnection than URLSession.

  • The Network framework WebSocket API exposes the full flexibility of the protocol, where URLSession only supports the basics.

  • Network framework has, in general, a bunch more features. For example, do you want your WebSocket connection to always run over WWAN? You can do that with Network framework but not with URLSession.

  • Network framework has server support.

  • My experience is that developers using the URLSession WebSocket API encounter way more reliability problems than folks using the Network framework one. This makes some sense theoretically — the URLSession implementation is layered on top of the Network framework one, so it can’t have fewer bugs — and I’ve found that it’s true in practice as well.

There are still some things that you can only do with URLSession [1]. Once that’s no longer the case, I’m going to advocate [2] for URLSessionWebSocketTask (and URLSessionStreamTask) to be officially deprecated, allowing URLSession to focus on its core competency, HTTP.

Oh, and speaking of HTTP, make sure you pay attention to Introducing Swift HTTP Types.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] For example, applying a custom proxy, although that’s changing this year.

[2] Keep in mind, however, that this is just my personal position, not a definitive Apple statement about The Future™.

@eskimo Thanks for the detailed answer! I feel like I understand the tradeoffs now.

I appreciate that Apple has internal style to stick to & whatnot, but in my personal opinion this bullet point would much enhance the technote:

URLSession is very much focused on HTTP, and WebSocket isn’t an HTTP-like protocol. While it uses HTTP under the covers, the actual WebSocket protocol is a reliably bidirectional connection with message framing. Those semantics are a much better match for NWConnection than URLSession.

That really cleared up for me why it was a generally good starting point, rather than "start with URLSession & use NWConnection when you need something special".

One last bit if you don’t mind — is there official documentation/tutorial/walkthroughs/etc. that explain making a WebSocket connection with NWConnection? It looks a bit more complicated to setup than URLSession & is definitely less familiar to me.

is there official documentation/tutorial/walkthroughs/etc. that explain making a WebSocket connection with NWConnection?

Officially, there’s Configuring a Wi-Fi Accessory to Join the User’s Network. That’s a pretty complex bea‍st though, so you might want to start with the trivial example here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Add a Comment