That crash appeared on my device (the crash is exactly the same, on application start) : dyld[48209]: Symbol not found: ($s10Foundation10URLRequestV10httpMethodSSSgvg) Referenced from: '/private/var/containers/Bundle/Application/F1B20444-7852-438D-8C81-99FAC68948A0/MyApp.app/Frameworks/WidgetsExtensionEngine.framework/WidgetsExtensionEngine' Expected in: '/System/Library/Frameworks/Foundation.framework/Foundation' Symbol not found: ($s10Foundation10URLRequestV10httpMethodSSSgvg) Referenced from: '/private/var/containers/Bundle/Application/F1B20444-7852-438D-8C81-99FAC68948A0/MyApp.app/Frameworks/WidgetsExtensionEngine.framework/WidgetsExtensionEngine' Expected in: '/System/Library/Frameworks/Foundation.framework/Foundation'

Ok, this was an error on the project's configuration. We manually linked the application's binary to an internal framework that itself linked on the Widget framework. Consider the problem solved. Thanks for the time

I'm trying to reproduce a scenario found in my app where a component used as a URLSession delegate is retained after its hierarchie has been released. This scenario is a problem in the case of unit tests, where instances of the component remain active because of that retain cycle across unit tests.

Another problematic scenario is the instanciation of the component used as a delegate in Notification Service Extension. It looks like the NSE is running out of memory after some time (and as such is getting violently killed), and we've noticed the component wasn't released across notification handling because of that last strong reference.

For additional information, in the real application testing code the situation is as followed : the URLSession.delegate is indeed set to nil after the "invalidateAndCancel" call, yet when looking at the memory object graph at the end of the test, an instance of __NSCFURLSessionDelegateWrapper class still holds a strong reference to it via a "_delegateWrapper" property of the urlsession. This delegatewrapper however doesn't seem to have anything holding strong references to it.

After the XCTestCase class is done using the _delegateWrapper wrapper though does the strong reference get released? Or better yet, when tearDownWithError is called does the strong reference get released? I'm not following you.. The TestCase class doesn't hold a reference to anything. Only the URLSession does, and it is instantiated by an object who should be released once the function inside the test goes out of scope. But to answer your question, i've setup a breakpoint in "tearDownWithError" and had a look at the memory graph, which still shows the DelegateObject as been retained by the "_wrapperDelegate" property of a __NSCFURLSessionDelegateWrapper instance.

I definitely hints of objects in autoreleasepool in the memory graph, however it looks to me that the object stuck in an autorelease pool is the __NSCFURLSessionDelegateWrapper instance, which i don't have any access to. I tried wrapping instanciateDelegateObjectAndInvalidateSession() function in an autorelease {} block, without any success.

I'm trying to understand the exact behavior of the URLSession objet regarding the release of its delegate. It's a quite important detail, that isn't totally explained by the documentation (it only states that the delegate will be released after the session is explicitely invalidated, but doesn't say when).

If your delegate is managing a ‘heavy’ resource, like a file handle, clean that up in -URLSession:didBecomeInvalidWithError: This only solves one part of the problem. The other is the following one : My delegate object is actually a component in a component hierarchy. I'm writing a unit test making sure that the hierarchy doesn't contain any retain cycle. This code works as follow : instantiate the root object in a local scope, iterate over all the sub-objects and create weak pointers to them in the parent scope exit the local scope test that all the weak pointers have been set to nil. Without any guarantee over the time at which the URLSession will release its delegate, there's nothing i can wait upon to make sure no retain cycle exists (because the URLSession itself creates that retain cycle). Now i got your point, and i think my solution will be to use an intermediate struct as a URLSessionDelegate, containing nothing but a weak pointer to the component, and simply forwarding all the calls to it. (and actually breaking the strong retain created by the URLSession). It will look hacky, but without more commitment on that side of the URLSession api, there isn't a lot more i can do.

Same here. Svg files in asset folder are not building anymore. I've seen this exact same problem occur in a not so distant past, such as here : https://developer.apple.com/forums/thread/731118?answerId=760613022#760613022 So Apple, i've got an idea : maybe people developping Xcode could start adding some god damn unit tests ? Screwing up the build of professional iOS developers that have no choice but use your tool is not ok !