Engineering Jedi: Maximize Connectivity in iOS 11

We’ve made you aware of things you should prepare for with iOS 11, now we’re looking at something more specific: how poor network connectivity will be handled with the upcoming iOS update. The lay user just needs to know you may use slightly more mobile data than you have before once you update to iOS 11. But for our fellow developers, we’re going deep into this subject below. Put on your engineer hats!

In iOS 11, Apple has made a number of improvements to the URLSession family of APIs. These improvements range from developer quality of life updates, to significant performance gains that will undoubtedly improve user experiences across the platform. In this post, we’ll go over two improvements in particular: Multipath TCP support and reachability monitoring built-in to URLSession.

Multipath TCP

Elegantly handling poor network conditions is a sure sign of a well-built and polished app.  Compared to most other apps on your phone, have you ever noticed how rarely Siri seems to have connectivity issues? The reason for this is Multipath TCP. When Siri makes a network request, the app actually opens up two connections to the server: one over Wi-Fi and one over cellular. These connections work together to deliver data to the app as quickly as possible. As long as your device has a decent connection on one of the two channels, Siri works.

Multipath TCP is a relatively new protocol, designed specifically for mobile devices. It is built on top of TCP, so it benefits from the reliability and congestion controls built into TCP. Additionally, MPTCP allows for seamlessly switching between a wireless and cellular connection. It even supports using both connections simultaneously to increase throughput (more on this later).

In order to take advantage of MPTCP, support is required at both the Client and Server level. Not all server infrastructures currently support MPTCP, but popular vendors like AWS do. With iOS 11, app developers can now support MPTCP at the client level as well.

Modes

In iOS 11, apps can opt into three different MPTCP modes: Handover Mode, Interactive Mode, and Aggregate Mode

• Handover Mode: Connection will be made over Wi-Fi when possible. If Wi-Fi network conditions are poor, the system will automatically spin up a cellular link and transfer the traffic to it. As Wi-Fi conditions improve, traffic will be transferred back to a Wi-Fi connection and the cellular link will be torn down. Essentially, handover mode attempts to minimize cellular usage while still maintaining acceptable performance. All of this happens in URLSession and is completely transparent to our apps.

• Interactive Mode: The system will immediately spin up both a Wi-Fi and Cellular link. While Wi-Fi is still preferred, the system will be aggressive about transferring to cellular if it finds that Wi-Fi conditions are not ideal. Interactive mode is optimized for performance, at the cost of cellular data usage. Siri uses Interactive mode.
• Aggregate Mode: Like Interactive mode, the system will immediately spin up two links. However, both links will be used together to increase the overall throughput of the network. In theory, using Aggregate mode over a 10mbps Wi-Fi connection and a 5mbps cellular network could result in a 15mbps connection to your server! While this is very cool, it can cause significant cellular data usage. Because of this, Apple is not allowing Aggregate Mode to run in Production apps. Aggregate mode is, however, available to developers via the Developer Settings screen in the Settings app.

Regardless of which mode is used, the cellular link will be disabled if your app hits the Wi-Fi assist data limit. Be on the lookout for this if you are testing your apps and notice MPTCP no longer switching over to cellular. This is a good indicator that you may need to rethink which calls are opted in to MPTCP.

Opting In

So, how do you opt in? Apple has made this extremely easy. Simply add the “multipath” capability to your app in Xcode, and set the multipathServiceType property on your URLSessionConfiguration to either .handover or .interactive. That’s it!

Reachability

Good reachability handling has always been tricky in iOS, mostly due to the absence of solid high-level support for it. Most apps use third- partyreachability libraries, all of which are built on top of Apple’s SCNetworkReachability low-level API. There are some issues with this approach: the libraries are not particularly reliable, and they are not integrated with URLSession. If a developer needs to hold off on making a network request until network conditions improve, or retry a network request, they have to build that functionality up from scratch themselves. That ends up being cumbersome for developers, results in less than ideal reachability handling, and also takes time away from polishing the user experience. Developers often take the easy route and present a full-screen modal as soon as connectivity is lost, blocking the user out of the app completely.

Apple has improved a number of these pain points in iOS 11. URLSession now has the ability to monitor network conditions and wait to start tasks. You can easily opt in to this behavior by setting waitsForConnectivity to true on your session’s configuration. When opted in to waitsForConnectivity, URLSession will either load the request immediately or load the request as soon as network conditions allow. While waitsForConnectivity is defaulted to false for backwards compatibility, Apple recommends enabling it for almost all requests.

In addition to delaying network requests, URLSession will now notify your app when it experiences poor connectivity. This is accomplished via the urlSession(_:taskIsWaitingForConnectivity:) delegate callback. You can hook into this delegate callback and use it to toggle Connectivity UI.

Do you have burning questions about connectivity with iOS 11? Our developers, responsible for numerous award-winning apps and connected device experiences, have the answers. Tell us what you’re wondering at [email protected].