Thanks for the response! Once you start generating large numbers of requests, you have to start thinking about where those requests stack up. Stacking up unbounded amount of work on an NSURLSession is bad, but it’s also bad to stack up unbounded amounts of work on a dispatch queue. What you need is flow control, that is, preventing the source from generating new requests until the system has had a chance to process some of the requests that are in flight. And how you do that really depends on the nature of the thing generating the requests. So, where are all these requests coming from? I'm working on the networking stack for a large app built by a large development team. In answer to your question, the requests come from all over the place — in response to user events, as periodic "make sure we're up-to-date" events, in response to push notifications, etc. I don't think we'll have anywhere near the level of thousands of requests being enqueued or in-flight at a time; I would think it's more on the order of a dozen or two, max.

Sorry to resurrect this old post, but I have two follow-up questions for you, Quinn: You mention that the max value (number of requests) is typically around a couple hundred; what happens if you go over that? Do you have recommendations for how to schedule requests outside of the session? NSOperationQueue and NSOperation subclasses?

One workaround I've found is to toggle the isNavigational property on the toggle sidebar item to false (in the toolbarWillAddItem(_ notification: Notification) callback). This seems like a bug.