2

From NSURLSession.h...

/* An optional array of Class objects which subclass NSURLProtocol.
   The Class will be sent +canInitWithRequest: when determining if
   an instance of the class can be used for a given URL scheme.
   You should not use +[NSURLProtocol registerClass:], as that
   method will register your class with the default session rather
   than with an instance of NSURLSession. 
   Custom NSURLProtocol subclasses are not available to background
   sessions.
 */
@property (nullable, copy) NSArray<Class> *protocolClasses;

Custom NSURLProtocol subclasses are not available to background sessions.

What would be the advantage of restricting custom NSURLProtocol subclasses to only trigger in foreground sessions?

72A12F4E
  • 1,744
  • 1
  • 14
  • 28

1 Answers1

1

From Apple documentation:

Background sessions are similar to default sessions, except that a separate process handles all data transfers.

Apple simply doesn't provide a way to inject your NSURLProtocol subclass into another process, managed by iOS itself.

Same restriction applies to WKWebView.

Borys Verebskyi
  • 4,160
  • 6
  • 28
  • 42
  • It is actually a bit more subtle than that. It would never inject your code into another process. Right now, background sessions call delegate methods in your app by using NSXPC. If your app isn't there, it does the best it can, and in some cases, your app gets relaunched. If protocol handling had to go through your app, it would never be able to do anything useful without your app running, which would completely break the background model at a fundamental level. For WKWebView, I can only assume the reason is the performance hit caused by all those XPC requests.... – dgatwood May 08 '16 at 02:43