Jeff Tu: Good afternoon, everyone. I'd like to welcome to you part two to Advances in Networking, a continuation of the session from the past hour. My name is Jeff Tu, and I'll be taking you through the first topic. In this session we'll discuss new URLSession developer API and enhancements, networking best practices, and other important technology areas in networking.

Our first topic is new URLSession API. But before that, I'd like to review the underlying API we'll be talking about, which is URLSession. URLSession is an easy-to-use API for networking introduced in iOS 7 and OS X Mavericks. URLSession supports networking protocols like HTTP/2; HTTP/1.1; FTP; and custom streams with an overall emphasis on URL loading.

If you provide it an HTTPS URL, it also automatically provides the encryption and decryption of data between you and the web server. Last year we deprecated NSURLConnection API. So we encourage any new app development to occur with URLSession. For more information on URLSession, I encourage you to review past WWDC sessions and other online documentation.

Recall that there are different kinds of URLSession objects that you can create. The basic object you can create is a default configuration URLSession object. Default sessions have a behavior where a task either fetches a URL immediately; or if the device can't connect to the web server, fails immediately.

URL loads can fail because the device isn't connected to the Internet or if the server you're trying to reach happens to be down. Those are just a couple of examples. Background URLSession objects, on the other hand, don't have this immediate fetch or fail behavior but are scheduled out of process and continually monitored for network connectivity to the server.

There are more examples of a URLSession task failing because of bad connectivity. You might have no Internet connection, you might be in a theatre with your device in Airplane Mode or it should be in Airplane Mode. Perhaps you have a session object where you've disallowed cell usage but the user only has cell connectivity. Or the server might only be accessible behind a VPN and the admin recently changed VPN access.

How do you as an app developer deal with a network load that fails? In the past, we've advised you to use the SCNetworkReachability API to monitor when you might have connectivity again to the server. Other approaches are polling every set period of time or depending on the user to tap or drag to refresh the UI. The problem is that these approaches add complexity to your apps and aren't always effective.

SCNetworkReachability only tells you that you might be able to reach the server, not that you will. You, our developers, have been asking for an easier solution. Wouldn't it be easier to say, then, "Please fetch me this resource when the network is available"? We're happy to tell you about a new feature that lets you do this. We call this the URLSession Adaptable Connectivity API. This --

This API is available now on all platforms. By opting into this API, you tell URLSession that in the event that the task would fail because of a lack of connectivity that it should wait for a connection to the server instead of failing. How do you opt in? There's a new boolean property called waitsForConnectivity. Set this to true, and then you get the new behavior.

I'd like to repeat what this property does. You go from the default behavior of load it now or fail now if I can't connect to load it now, but if I can't and would have failed because of a lack of connectivity, try again when I get a real chance to talk to the server.

The API also waits when it encounters DNS failures as well since one network's DNS service might fail to resolve but another one may not. Please note that this boolean is a no op for background sessions, as background URLSession objects get this behavior automatically. We'll tell you later in this hour more about the differences.

You may be wondering, "Can my code get a notification if it's in this waiting state?" You might want to have the app present other behavior while it's waiting to connect. For example, having an offline browsing mode or a mode that operates when the user is only on cell.

If you would like to know when your app is in this waiting state, you can optionally implement the URLSession taskIsWaitingForConnectivity delegate method. Note that this delegate method is only called if you've opted into the waitsForConnectivity property with a true value. If you've done this, the delegate method itself will be called only one time or not at all if the task never had to wait.

We recommend that your apps always opt into the waitsForConnectivity property. This is because even when you opt in, the task will still try to run immediately. The task will only wait if it can't connect to the server. There are rare exceptions to opting into the property, though. For example, if you had a URLSession task whose purpose was to buy stock at market price, you'd want that to run now or fail now and not wait until you had an Internet connection. I'd also like to mention that when you opt into waitsForConnectivity, the timeout interval for request timer starts only after you've connected to the server. Timeout interval for resource, however, is always respected.

Let's summarize how we would use the API and then go through a code example. The main thing is to opt into the waitsForConnectivity property. You would create and resume the URLSessionTask as before. If the device can't connect to the server, we'd call a delegate callback if you implemented it and only once. All other URLSession methods are still called same as before. Remember, though, that this API only has an effect for non-background sessions.

Let's go through a sample code. First create a session configuration object and make one for default session type. Opt into the waitsForConnectivity property. Create the session object and set the URL you want to load. Use the session object to create a task object. And finally, resume the task to get it started.

Even with adaptable connectivity, your request may still fail for other reasons. For example, you could connect to the server, but a new data center employee might unplug a server, cause the network connection to drop, and all your apps on your phone might disappear. Or your device connects to the server and sends an HTTP request, but there's so much traffic that the request times out. For situations like these, we'd like you to consult online resources that go into more detail on what you can do. Retrying network loads in a tight loop, though, is almost always a bad idea.

You asked for a better way to load network resources. Better than polling for network connectivity to the server and better than reachability API that won't guarantee a connection to the server. Let URLSession do the work for you. Opt into the waitsForConnectivity Adaptable Connectivity API. If you opt in, the request will still run immediately with no performance penalty and only wait if you can't connect to the server. Once it can connect, your URLSession task behaves just like it did before. Continuing our theme of what's new, I'd like to pass the mic to my colleague, Jeff Jenkins.

Thanks, Jeff. Well, good afternoon. Hope you guys are having a great WWDC. And I'm exciting to be here and thrilled to talk to you a little bit more about some enhancements we've made to the URLSessionTask API. Now, first I want to spend a little bit of time talking about background URLSession. We haven't talked a whole lot about it, so let me give you a little bit of background on that. The background session URLSession API allows your application to perform networking even if your process, your application isn't running.

We monitor the system conditions, CPU, battery, all sorts of things to really find of right time to do your networking tasks. Now, of course, if you implement various delegate methods, we're going to wake up your app and call those delegate callbacks so that you can handle that information. And, of course, we're going to make sure your app is running when your task completes so that you can then process that data. Now, one of the great use cases for background URLSession is taking advantage of another feature on the system, which is background app refresh.

Now, what this really does is allows your application to have the most current, the freshest data, right? There's nothing more frustrating than pulling your device out, launching an app, and the first thing you're greeted with is some sort of spinner, right? You're waiting for this application to start pulling down data.

You want that data right away. You want to be able to get that data to your user so your user is excited and happy to use your app. Background app refresh is a way to do this. It's a way to tell the system that, "Hey, in the future I want to be able to be launched so that I can refresh my data so I have the most important information," maybe stock information, or weather forecast, other important things that your app does. Now, this applies to applications, as well as watchOS complications. And if you want to learn a little bit more in depth about background app refresh, you can go back to 2013 WWDC, as well as last year's 2016 WWDC and look at these sessions for more details.

So let's look at background app refresh in action; what is it really doing? And to do that, we kind of need to look at the state of your application. We're interested in three states here: A running state, suspended state, or a background state. Now, with your app running, you're going to opt into background app refresh. You're going to say, "In the future, run my app, make sure my app runs so that I can get the latest information." And then your process could be suspended.

And in the future your process is now running, your app is now going to be able to ask for new data. And like good developers, this app is using URLSession API. In fact, it uses a background URLSession. It creates a URLSession task and schedules this task to run and grab the data that your application needs.

Now, your process could go away at this point, but then at some point URLSession is going to run your task and it's going to run it to completion hopefully if everything goes well. And you're going to get the data. So we're going to background launch your application and allow you to process that completed task and process that data that we've fetched for you.

And then at some point the user is going to launch your app, it's going to come foreground, and boom, they've got the freshest data there. So this is great. But we looked at this flow and said, "Hmm, maybe there's something we can do to help our developers improve their applications on our platforms." And we think we can do something for you.

The first problem that we want to solve is we noticed there's an extra background launch that had to happen just for you to create the URLSession task. And as we all know, anytime your process is launched, what does that do? It impacts battery life, requires CPU burden. So that's not necessarily great for the device if we're doing extraneous work, and we really don't need to be doing that.

The other problem we'd like to solve are stale network requests, right? You're asking URLSession to do work. And at some point in the future, that work is going to complete. Well, what happens between when you ask for the work to be done and when it actually got done? Maybe there was some change in context and that original request doesn't make sense anymore. So we need to give you an opportunity to really, if there's a context change, let us know about that and get rid of these stale network requests. Because there's nothing worse than getting data and going, "I can't do anything with it," and throw it away.

And the last problem we think we could help you with is helping us know how to best schedule your URLSession tasks. When is the most optimal, best time in the system to be able to run your task so that we can get your data in the most efficient way for you to display that so that your users are excited and delighted by that data? Let's look at what we did.

We're introducing the URLSessionTask scheduling API. Now, this is available across all of our platforms. It's available in the beta builds that you have received here at WWDC. And we encourage you to take a deep look at this. Now, what we've done first is we provided a new property. This is a property on URLSessionTask object. It is called earliestBeginDate.

And what you're going to do here is provide a date to us in the future when you want your task to be eligible for running. I use that word eligible because it's important. It doesn't mean that this is the point in time when your task will run, it will do networking; it's just telling the system, "I would like my task to be eligible so that it can run." And we're still bound by system policies as to when we can make the networking happen for this task. It's only applicable to background URLSessions and tasks built off of background URLSession.

Let's take a look at how this property in conjunction with other existing properties really allows you to do some fine-grain scheduling. So you'll create a URLSessionTask and, of course, you'll call resume on it so that we know that this task can now be put into the queue so that work can happen.

You'll -- and at this point the task will be in a waiting state. We're waiting for the earliestBeginDate to happen. And as soon as that is hit, that task becomes eligible for running. Now, you can use the existing timeoutIntervalForResource to really control how long your app is willing to wait for at that resource to get loaded, right? You might set some amount of time to say, "After this point in time, this resource isn't interesting to me anymore." And that interval of time covers from resume to when that timeout happens based on the value you place in timeoutIntervalForResource.

Now, I want to go back to the original background app refresh workflow that we looked at earlier. Right? We noticed there was a couple of background launches that occurred. But with this new API we're able to get rid of one of those. So the way that your app will work is while your running, you're going to create a URLSessionTask; you'll opt into our new scheduling API by setting an earliestBeginDate; then your process can go to sleep. We're going to complete the work for you.

And when that work is available, we're going to background launch you that one time and allow you to process the resulting data. And then when the user brings your app to the foreground, boom, it's got the freshest, most current data. And we've been able to solve that one problem of that additional background app launch. And so it's better performing on the system, and we think that's great.

So that's problem number one solved. Let's look at problem number two, the stale network fetches. We want to give you an opportunity to alter future requests. So you might have given us a request, but the context might change. We've introduced a new delegate callback on a URLSessionTaskDelegate titled willBeginDelayedRequest.

With this delegate, you'll be able to be called at the moment when your task is about to start networking. So it is you've told this that the task is eligible and the system now has decided yes, this is the right time to do the networking. We're going to call this delegate method, if you implement it, and allow you to make some decisions about this task. Now, this will only be called one, if you implement it; also, if you opt into the scheduling API by setting an earliestBeginDate. And, again, this is only available on background URLSessions.

And as I mentioned, this is an optional delegate. And I want to take a second here to have you really think about this because it's important, this delegate method. As with all delegate methods, they're all opt into. But this one will cause some interesting side effect that I'll show you in a minute. You really need to think about, "Can my application determine context, the viability of a request in the future?" Now, there's a completion handler that's passed to this delegate method.

And you need to give a disposition to URLSession. You need to tell us does the original request, does it still make sense? Go ahead and proceed. Or maybe the context has changed enough and you need to make some modifications, maybe a different URL or maybe a header value's different and you want to go ahead and modify that request at this point in time right before the networking happens. Or you might make the decision this request is just useless at this point, cancel.

We don't want to do stale requests. So now if we go back to this workflow and we go back to my comment about really thinking about this delegate method, you will see that we're kind of back to that original workflow where there's two background launches in order to satisfy this URL task.

Right? But we have to stop and think about that. What is more expensive, performing a stale network load or a mere application background launch? It is way more expensive to the system to do stale loads, get all this data, and then decide I don't need it and pitch it. Okay? So we want you to really think about this new delegate method and whether your application has the ability to really understand the viability of your requests in the future. Hopefully that make sense to you.

Now, the third problem we want to solve is how do we schedule your request in a most optimal, most intelligent way in our system? There's some information that in URLSession we just don't know about. So we're providing a little bit of change to our API to allow you to explain to us some information about your requests and also about your responses.

We're giving you two properties, the first one is countOfBytes ClientExpectsToSend, and the second one is countOfBytes ClientExpectsToReceive. We think you know more about your requests. Maybe you have a stream body that you want to attach to a request, we don't know about that. You probably know the size of that.

We don't know about your servers and the size of data your servers' shipping back. We believe you have some insight to that. And that will give us hints as how we can in a most optimal, intelligent way schedule your tasks. If you don't know, well, then you can always specify NSURLSessionTransferSizeUnknown.

So that solves the third problem. Let's take a look at how this new API works in code. It's very easy to use. First thing we're going to do is create a URLSession background configuration. We're then going to create a session based on that configuration. Once we have that, we're going to now generate a URLRequest, specify the URL we want to go to, maybe set a header value, something that makes sense for your task. Again, this is just an example.

And now we're going to create a task that encapsulates that request on that session. And we're going to opt into the new scheduling API by setting the earliestBeginDate property and give us a date. In this example we say two hours from now I want this task to be eligible to be run.

And I'm also going to give some hints to URLSession and say, "This is a small request, there's no body, I've just set one header, maybe 80 bytes." And then my server probably is going to send about a 2K response to this. And with all URLSession tasks, make sure you call resume.

Now, how does the new delegate work? Well, we decided I know context. I can make some intelligent decisions about my networking tasks in the future. So I've implemented willBeginDelayedRequest. So in our example here what I've decided to do is to modify the request. I'm going to take the original request, create a new updatedRequest. I'm going to maybe change a value in the header that makes more sense now that this task is actually going to do some networking.

Time has passed, I have new information. I put that information on that task. And then I'm going to call the completionHandler and use a disposition of useNewRequest and passed it that new request. If you take a look at our header file, you can see other dispositions available to you in this completionHandler call.

So let me recap the scheduling API that we're introducing here. Background URLSession is an awesome API for doing networking that allows your application to not even be running and have this networking happen for you. Our new scheduling API will allow you to delay your requests so that they can, you know, obtain and pull down the freshest information for your application.

And it's really we give you an opportunity to alter those things based on the context and the time at when the networking is actually going to happen. The other part of this API change is to allow you to give hints to us so that we can be super intelligent and make these tasks run at the most optimal time on these devices. Now, I'd like to turn the time over to Stuart Cheshire, an Apple distinguished engineer. And thank you for your time.

Thank you, Jeff. Now we're going to talk about enhancements in URLSession. We have four things to cover, let's move through them. Often you want to show a progress bar to indicate to the users how progress is being made. And right now this is a little bit cumbersome. There are four variables that you need to monitor with Key-value Observing. And sometimes the countOfBytesExpectedToReceive or Send is not always available.

The good news now in iOS 11 is URLSessionTask has adopted the ProgressReporting protocol. You can get a progress object from the URLSessionTask, and that gives you a variable fractionCompleted, which is a number in the range zero to one. You can also provide strings to give more detail about what the operation is. You can attach that progress object to a UIProgressView or an NSProgressIndicator to get an automatic progress bar.

You can also combine multiple progress objects into a parent progress object when you're performing multiple tasks, such as downloading a file, decompressing a file, and then handling the data. So that makes your progress reporting much simpler. The binding between a URLSessionTask and the progress object is bidirectional. So if you suspend a URLSessionTask, that is the same as pausing the progress object. If you pause the progress object, that is the same as suspending the URLSessionTask.

We now have support for the Brotli compression algorithm. In tests this compresses about 15% better than gzip, which results in faster network access. Like other new compression schemes, this is only used over encrypted connections to avoid confusing middle boxes that might not recognize this compression. Because Safari uses URLSession, that's also means Safari gets the benefit of this new Brotli compression algorithm. And many major websites have already announced support for Brotli in their web service.

Our next topic is the Public Suffix List. The Public Suffix List is sometimes called the effective top-level domain list. And this is important for determining where administrative boundaries occur in the namespace of the Internet. One thing we don't want to allow is for a website to set a cookie on the com domain, which is then accessible to any other dot com company. So you might be tempted to make a rule that you can't set cookies on top level domains, only on second level and lower.

But domains are named differently in different parts of the world. In America, Apple.com and FileMaker.com are different companies. But in Australia many, many companies are under com.au, and that doesn't make them all the same company. So the Public Suffix List is a file of rules and patterns that tells software how to judge where administrative boundaries occur.

This is used for partitioning cookies, and it's used by the URLSession APIs. And if you use the HTTPCookieStorage APIs directly, it's supported there, too. We used to update this in software updates, but now with the more rapid progress in creating top level domains, we've changed to doing this over the air. We could push a new list every two weeks if we wanted to.

URLSessionStreamTask is the API you would use if you just want a byte stream. If you're not doing HTTP Style Gets but say you want to write a mail client, URLSessionStreamTask gives you a simple byte stream. It supports upgrading to TLS with the STARTTLS option. If you have existing code that is written using the old NSInputStream and NSOutputStream APIs, you can extract those objects from a URLSessionStreamTask to use your old code. But for any new code you're writing, we strongly recommend that you use the new native URLSessionStreamTask APIs.

We announced this a couple of years ago at WWDC 2015. What we have new for you now is automatic navigation of authenticating proxies. If the proxy requires credentials, then we will automatically extract those from the key chain or promptly the user on your behalf. So we've covered the enhancements for URLSession, let's move on.

Thank you. Tips and hints that we've learned from our years helping developers. Number one rule: Don't use BSD Sockets. And by the same token, we encourage you not to embed libraries that are based on BSD Sockets. Because we do lots of work, as you've been hearing today, to provide benefits to your applications.

We provide Wi-Fi Assist so that your application succeeds instead of failing when Wi-Fi isn't working. We provide techniques to minimize CPU use and minimize battery use to give users longer battery life. We have the ability to do tasks in the background when your application isn't even running. And the third-party libraries just can't do anything when they're not in memory running.

And final bit of advice: Always try to use connect-by-name APIs as opposed to APIs where you resolve a name to an IP address and then connect to the address. We talked earlier about the requirement for IPv6 support. And the reason that almost all of your apps worked perfectly is because when you use connect-by-name APIs, you don't get involved with the IP addresses. And if you're not involved with the IP address, you don't need to care whether it's v4 or v6, it just works.

Another question we often get is about the timeout values. So I want to recap that. The timeoutIntervalForResource is the time limit for fetching the entire resource. By default, this is seven days. If the entire resource has not been fetched by that time, it will fail. timeoutIntervalForRequest is a timer that only starts once the transfer starts. Once it starts, if your transfer stalls and ceases making progress for that time-out value, that when that timer will fire.

We have seen developers that take their old NSURLConnection code and convert it to the new URLSession code by mechanically making a URLSession for every old NSURLConnection they used to have. This is very inefficient and wasteful. For almost all of your apps what you want to have is just one URLSession, which can then have as many tasks as you want.

The only time you would want more than one URLSession is when you have groups of different operations that have radically different requirements. And in that case you might create two different configuration objects and create two different URLSessions using those two configuration objects. One example is private browsing in Safari where each private browsing window is its own separate URLSession so that it doesn't share cookies and other states with the other sessions. Most apps can just have one statically-allocated URLSession, and that's fine. But if you do allocate URLSessions dynamically, remember to clean up afterwards. Either finish tasks and invalidate or invalidate and cancel. But if you don't clean up, you'll leak memory.

We get developers asking us about convenience methods and delegate callbacks. Delegate callbacks give you detailed step-by-step progress information on the state of your task. The convenience methods, like the name suggests, are a quick and easy way of using the API. With convenience methods you don't get all the intermediate delegate callbacks, you just get the final result reported to the completionHandler.

Don't mix and match both on the same URLSession, pick one style and be consistent. If you're using the completionHandler, you will not get the delegate callbacks with two exceptions. If networking is not currently available and the task is waiting for connectivity, you'll be notified of that in case you want to show some indication in your UI. The other delegate method you may get notified is the didReceive AuthenticationChallenge.

So here's a summary of the options available to you. Doing URLSessionTasks in your process with waits for connectivity as we recommend, the task will start immediately if it can; or if it can't, it will start at the first possible opportunity. You also have the option of doing tasks in the background. And you can do background discretionary tasks, which will wait until the best time in terms of battery power and Wi-Fi networking.

Now I have a couple of ongoing developments to talk about. I'm sure many people in this room have heard about TLS 1.3. TLS, Transport Layer Security is the protocol that encrypts your data on the network to prevent eavesdroppers from seeing it and perhaps as importantly to make sure that you have connected to the server you intended to connect to.

TLS 1.2 is very old at this stage. It has a number of problems that have been discovered. And TLS 1.3 is almost finished. That standard is not quite finalized. Apple is participating in that IETF working group, and we expect that to be finished by the end of this year. In the meantime, we do have a draft implementation if you want to experiment with it right now. And if you check out the security session from this Apple Developer Conference, you can learn how to experiment with that.

Another thing you may have heard of is QUIC. QUIC is a new transport protocol designed to experiment with new ideas that are hard to do with TCP. QUIC started out as an experiment by some Google engineers, and it was a very successful experiment. They learned a lot. Some ideas were good, some turned out not to work as well as they hoped.

Those engineers have taken those lessons they learned to the IETF. We have formed a new working group to develop the IETF standard QUIC protocol. Apple is also participating in that working group. That is not nearly as far long as TLS is, but that is also making good progress.

Before we finish, one other thing we should talk about, Bonjour. Fifteen year ago at this very convention center in San Jose, Steve Jobs announced Bonjour to the world. And I got the opportunity to tell you all how it worked. A lot has happened since then. Since we launched it in 2004, we brought out Bonjour for Windows, for Linux. We had Java APIs. The next year Mac OS X 10.4 introduced wide-area Bonjour to complement the local multicast-based Bonjour that was in the original Mac OS 10.2 launch. The same year the Linux community came out with a completely independent GPL-licensed implementation of Bonjour called Avahi.

A couple of years after that, Apple shipped Back to My Mac, which is built on the wide-area Bonjour capabilities introduced in 10.4. And in 2009 we brought out the Bonjour Sleep Proxy, which let you get Back to Your Mac at Home, even when it was asleep to save power.

In the years since then, Android adopted with Bonjour with their own native APIs in 2012. That was in API Level 16 for those of you paying attention. And a couple of years ago, Windows 10 added their own native Bonjour support. Now, I know a lot of people in this room are well aware of the history. We know about the major OS vendors adopting Bonjour.

But something else happened that surprised even me: Bonjour started showing up in a lot of other places. And I want to illustrate this with just a little personal anecdote. I recently bought a new house. And as part of the process of buying a new house, you often end up buying a bunch of new stuff. And I started adding things to my home and connecting things to the network.

And I started finding a bunch of stuff showing up in Bonjour. Now, I bought a new printer; it had Bonjour. I bought some Access Network security cameras, they had Bonjour. That didn't surprise me because we know printers and network cameras were among the first devices to adopt Bonjour.

But then I got a surround sound amplifier and it had Wi-Fi, and it had an embedded web server with Bonjour. Now, you can set up the amplifier with the TV and the remote control, but naming the inputs with up, down, left, right on the remote control one character at a time is really tedious. Being able to do this on my laptop or on my 27-inch iMac with a keyboard and a mouse is such a nicer way to set up a new piece of equipment. I bought another amplifier from different company, it also had Bonjour.

I got solar panels on the roof of the house to save on the electricity bill, the inverter has Wi-Fi with an embedded web server advertised with Bonjour. So now with one click, I can see a graph of how much power I've produced in the day. My most recent purchase was an irrigation controller to control the sprinklers that water my lawn. It has Wi-Fi with an embedded web server advertised with Bonjour. Compared to trying to program your garden sprinkles with a two-digital LCD display and the plus minus buttons, this is such a glorious experience to see it all on my big iMac screen at the same time.

So thank you to all you device makers who are making these wonderful products. For the app developers in the room, how does this affect you? The IETF DNS Service Discovery Working Group continues to make progress. We have new enhancements to do serve discovery on enterprise networks where multicast is not efficient and on new mesh network technologies that like Thread that don't support multicast well.

The good news for app developers is this is all completely transparent to your apps. The APIs haven't changed because we anticipated these things even 15 years ago. The only thing to remember is when you do a browse call and you get back a name, type, and domain, pay attention to all three. You may be used to see the domain always being local, but now it may not be local.

So when you call resolve, make sure to pass the name, type, and domain you got from the browse call. And for the device makers out there, don't forget to support link-local addressing. Link-local addressing is the most reliable way to get to a device on the local network because if you can't configure it, you can't misconfigure it.

So to wrap up, in part one we talked about ongoing progress in ECN. It's now supported in clients and servers, the stage is set. Any ISP can now see an immediate benefit for their customers by turning on ECN at the key bottleneck links. Continue testing your apps on NAT64. Mostly known use there, we're very happy everything is going smoothly.

We have a move to user space networking, which also doesn't change the APIs. But you may notice when you're debugging and looking at stack traces, you may see symbols in the stack trace you're not used to. You may see differences in CPU usage. We wanted to you to be aware of that so it didn't surprise you. We have new capabilities in the network extension framework. And the big news, we have multipath TCP as used by Siri now available for your apps to use as well. Thank you.

In part two, we covered some enhancements in URLSession, especially the waitsForConnectivity, which is really networking APIs done the way they always should have done. When you ask us to do something, we should just do it, not bother you with silly error messages that it can't be done right now. You ask us, we will do it when we can. I gave some tips about best practices and news about ongoing developments. You can get more information about this session on the web. We have some other sessions we recommend you hear that you'll probably find interesting. Thank you.