In iOS 16.1 there are two memory-access issues that have surfaced in related to NSFetchedResultsController: If your sectionNameKeyPath returns an ordering that doesn't match that of the fetch request's first sort descriptor, the internal NSError instance created to warn you of this fact gets over-released and may crash the application. If your implementation of sectionNameKeyPath is a computed property implemented in objective-c, the fetched results controller may crash due to over-releasing the returned strings (it's possible this may also happen in Swift, though I was unable to produce the behavior). I've filed two feedbacks (FB11652942 & FB11653996) regarding these issues, but also wanted to raise them here in case that may help expedite their resolution. The offending method seems to be -[NSFetchedResultsController _computeSectionInfo:error:], which, from inspecting the disassembly, appears to now contain some references to objc_autoreleasePoolPop which were previously absent. Regarding issue 2. specifically – it's unclear what the ownership model for the value returned from sectionNameKeyPath is intended to be if said key path produces a computed value. Does the fetched results controller take ownership of it, or does the framework assume that the corresponding managed object is the owner? -Jamie

Hi, I'm investigating what looks like possibly nondeterministic behavior when linking large iOS app binaries. I do not have a concise reproduction of the issue yet, but am trying to hunt down possible leads. In particular, the problem appears to surface when invoking clang to link a binary and the resulting order of the 'branch island' instructions appears to be random each time the binary is linked (as shown by the link map output). I was wondering if anyone with insight into the linker's current implementation could shed light on whether that is expected, and if there is anything that can be done to prevent it. FWIW, it seems like it might be size-dependent as smaller app binaries don't appear to exhibit the same behavior. I'd be glad to share more specifics and hopefully a reproduction if I can ever find one eventually. Some environment info (Xcode 16.4 toolchain): clang -v: Apple clang version 17.0.0 (clang-1700.0.13.5) Target: arm64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Applications/Xcode-16.4.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ld -v: @(#)PROGRAM:ld PROJECT:ld-1167.5 BUILD 01:45:05 Apr 30 2025 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 17.0.0 (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 17.0.0 (tapi-1700.0.3.5)

In the 'Discussion' section of the current documentation for Swift's DispatchQueue, it says: If the target queue is a concurrent queue, the blocks run in parallel and must therefore be reentrant-safe. However, unlike dispatch_apply (on which this API is built), this method provides no direct means of specifying a target queue, so this callout is somewhat more confusing than it ought to be. IMO, it's important to highlight the reentrancy considerations that apply in most (all?) cases, but the implicit reference to the implementation details should be removed or clarified. Feedback filed as: FB13708750

I can't seem to find much documentation on the observe(_:options:changeHandler:) method itself. There is this page which has some example use, but there is no link to a 'real' documentation page for the method. Additionally the 'quick help' has a little bit of info, but no parameter definitions or explanation of if/how the return value or changeHandler closure are retained.

I was wondering if there is a way, while debugging, to observe the 'QoS boosting' behavior that is implemented in various places to provide priority inversion avoidance. The pthread_override_qos_class_start/end_np header comments specifically say that overrides aren't reflected in the qos_class_self() and pthread_get_qos_class_np() return values. As far as I can tell the 'CPU Report' UI in Xcode also does not reflect this information (perhaps for the reason the header comments call out). Is there a direct mechanism to observe this behavior? Presumably a heuristic empirical test could be done to compare throughput of a queue that should have its priority boosted and one that should not, but I would prefer a less opaque means of verification if possible. Thanks in advance!

NWPathMonitor appears to retain itself (or is retained by some internal infrastructure) once it has been started until cancelled. This seems like it can lead to memory leaks if the references to to the monitor are dropped. Is this behavior documented anywhere? func nwpm_self_retain() { weak var weakRef: NWPathMonitor? autoreleasepool { let monitor: NWPathMonitor = NWPathMonitor() weakRef = monitor monitor.start(queue: .main) // monitor.cancel() // assertion fails unless this is called } assert(weakRef == nil) } nwpm_self_retain()

Per my understanding of the DispatchQueue docs, and various WWDC videos on the matter, if one creates a queue in the following manner: let q = DisqpatchQueue( label: "my-q", qos: .utility, target: .global(qos: .userInteractive) ) then one should expect work items submitted via async() to effectively run at userInteractive QoS, as the target queue should provide a 'floor' on the effective QoS value (assuming no additional rules are in play, e.g. higher priority items have been enqueued, submitted work items enforce QoS, etc). In practice, however, this particular formulation does not appear to function that way, and the 'resolved' QoS value seems to be utility, contrary to what the potentially relevant documentation suggests. This behavior appears to be inconsistent with other permutations of queue construction, which makes it even more surprising. Here's some sample code I was experimenting with to check the behavior of queues created in various ways that I would expect to function analogously (in regards to the derived QoS value for the threads executing their work items): func test_qos_permutations() { // q1 let utilTargetingGlobalUIQ = DispatchQueue( label: "qos:util tgt:globalUI", qos: .utility, target: .global(qos: .userInitiated) ) let customUITargetQ = DispatchQueue( label: "custom tgt, qos: unspec, tgt:globalUI", target: .global(qos: .userInitiated) ) // q2 let utilTargetingCustomSerialUIQ = DispatchQueue( label: "qos:util tgt:customSerialUI", qos: .utility, target: customUITargetQ ) // q3 let utilDelayedTargetingGlobalUIQ = DispatchQueue( label: "qos:util tgt:globalUI-delayed", qos: .utility, attributes: .initiallyInactive ) utilDelayedTargetingGlobalUIQ.setTarget(queue: .global(qos: .userInitiated)) utilDelayedTargetingGlobalUIQ.activate() let queues = [ utilTargetingGlobalUIQ, utilTargetingCustomSerialUIQ, utilDelayedTargetingGlobalUIQ, ] for q in queues { q.async { Thread.current.name = q.label let threadQos = qos_class_self() print(""" q: \(q.label) orig qosClass: \(q.qos.qosClass) thread qosClass: \(DispatchQoS.QoSClass(rawValue: threadQos)!) """) } } } Running this, I get the following output: q: qos:util tgt:customSerialUI orig qosClass: utility thread qosClass: userInitiated q: qos:util tgt:globalUI-delayed orig qosClass: utility thread qosClass: userInitiated q: qos:util tgt:globalUI orig qosClass: utility thread qosClass: utility This test suggests that constructing a queue with an explicit qos parameter and targeting a global queue of nominally 'higher' QoS does not result in a queue that runs its items at the target's QoS. Perhaps most surprisingly is that if the target queue is set after the queue was initialized, you do get the expected 'QoS floor' behavior. Is this behavior expected, or possibly a bug?

i’ve seen evidence that UIViewController has logic to prevent its dealloc/deinit methods from running on a background thread. what seems to occur is that, if the last strong reference to a UIVC is zeroed off the main thread, then the VC is logically marked as ‘deallocating’, but actual invocation of dealloc/deinit is enqueued to the main queue. during the window of time between the beginning and end of this asynchronous deallocation, some strange issues can occur. in particular, if the deallocating VC is a parent view controller, then its children can still access it via their parent property. despite this property being marked as weak, a non-nil parent VC reference will be returned. if a weak reference is attempted to be stored to the parent, you get a runtime crash immediately to the effect of: Cannot form weak reference to instance (0x1234) of class <some-UIVC-sublass>... surprisingly, if you load the reference via the objc runtime's objc_loadWeak method, you'll get nil, but no crash. unsurprisingly, if a strong reference to the deallocating parent is stored and persists past its dealloc invocation, you’ll generally end up with a segmentation violation if the reference is accessed. i imagine the UIVC source is quite complex and there are probably good reasons to try and ensure deallocation only ever occurs on the main thread, but it seems surprising that simply passing view controller variables across threads could lead to exposing unsafe references like this. is this behavior expected? assuming not, i've preemptively filed feedback FB13478946 regarding this issue. attached is some sample code that can reliably reproduce the unexpected behavior. UIKitAsyncDeallocCrashTests.swift