eskimo

If you're dealing with App Transport Security (ATS), here's one small snippet from the OS X El Capitan Developer Beta 6 Release Notes that you might have missed (I know I did)...The nscurl tool on OS X El Capitan supports diagnosing ATS secure connections. For example, /usr/bin/nscurl --ats-diagnostics https://www.example.com will display ATS connection information for www.example.com. Run /usr/bin/nscurl -h for more information. The nscurl tool is useful in general, but this option is particularly valuable when debugging ATS issues. In addition, if you’re trying to work out exactly what TLS parameters your server supports, one good option is to connect to it using TLSTool. For example:$ TLSTool s_client -connect forums.developer.apple.com:443 * input stream did open * output stream did open * output stream has space * protocol: TLS 1.2 * cipher: ECDHE_RSA_WITH_AES_256_GCM_SHA384 * trust result: unspecified * certificate info: * 0 rsaEncryption 2048 sha256-with-rsa-signature 'forums.developer.apple.com' * 1 r

Note Much of this content has been rolled into URL Loading System documentation, but I’m leaving this doc here for my own reference. URLSession background sessions are optimised for transferring a small number of large resources. Moreover, it’s best if the transfer is resumable. This design makes the best use of client device resources and the available network bandwidth. If your app runs a lot of tasks in a background session, you should rethink its design. Below you’ll find a number of options you might consider. Most of these options require server-side support. If your server does not have this support, and you can’t add it — perhaps you’re writing a client app for a server you don’t control — you won’t be able to implement these options directly. In that case consider creating your own server that sits between your app and the final server and implements the necessary smarts required to optimise your app’s network usage. If that’s not possible, a final option is to not use a background session but instea

IMPORTANT The resume rate limiter is now covered by the official documentation. See Use background sessions efficiently within Downloading files in the background. So, the following is here purely for historical perspective. NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background. It works as follows: nsurlsessiond (the daemon that does all the background session work) maintains a delay value for your app. It doubles that delay every time it resumes (or relaunches) your app. It resets that delay to 0 when the user brings your app to the front. It also resets the delay to 0 if the delay period elapses without it having resumed your app. When your app creates a new task while it is in the background, the task does not start until that delay has expired. To understand the impact of this, consider what happens when you download 10 resources. If you pass them to th

Debugging code that runs in the background on iOS is tricky because the act of running your app in the debugger affects how it behaves. This is especially true with URLSession background session code. I regularly see folks confused about how to test and debug such code, and this is my attempt to help with that. If you have questions or comments about this, start a new thread and tag it with Foundation and CFNetwork so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com Testing Background Session Code Testing an app that uses a URLSession background session is tricky because of the differences between the test environment and the production environment. This post explains those differences and describes how you can effectively test your background session code. Confusing Behaviours When testing background session code you might encounter four common sources of confusion: When you run your app from Xcode, Xcode ins