Recent Comments

Open Radar FB13754641: Quicklook operation for a single VCF (contact) file requires access to entire Contacts database even though technically not necessary

Apple feedback

Just got a note from Apple that this is now being look into. No confirmation that they can reproduce it, yet.

By tempelmann at May 20, 2024, 7:54 p.m.

Open Radar FB13471297: Equivalent tracks API returns incorrect track


We believe this has been improved, please verify and let us know.

By at May 18, 2024, 1:13 a.m.

Open Radar FB13453582: macOS 14 Sonoma ikev2 vpn rekey sends invalid proposals, causing a disconnect every 24/48 minutes, error NoProposalChosen

Same happens me

Do you have any idea how to solve it? is a lot frustrating to reconnect every 24mins

By engels.medina at May 2, 2024, 4:37 p.m.

Open Radar FB13445046: Cascade delete does not work


I am still able to reproduce the issue with iOS 17.5 Beta 2. See the attached screenshot. I have circled the issue in red. After deleting the parent, the child is still alive and its parent relationship is set to nil.

Are you sure you checked the right store? The sample application uses an in-memory store.

By at May 1, 2024, 4:34 a.m.

Open Radar FB13445046: Cascade delete does not work


After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue:

We checked the store before and after the deletion of the parent was performed and the delete cascades- objects from both sides of the relationship are deleted. Tested with the sample application provided.

Please close this feedback report, if there's nothing else you need from us here.

By at May 1, 2024, 4:34 a.m.

Open Radar FB13758633: Expose Total Store Ordering to applications

The QEMU project tracks the issue at:

By akihiko.odaki at April 27, 2024, 8:07 a.m.

Open Radar FB13363786: SwiftData crashes when saving certain types of enum cases



Thank you for filing the feedback report. We made changes to our system. Please verify this issue with iOS 17.5 beta and update your bug report with your results by logging into or by using the Feedback Assistant app.

iOS 17.5 beta (Build: 21F5048f) Posted Date: April 2, 2024

If resolved, you can close your feedback by choosing the Close Feedback menu item in the Actions pop-up in Feedback Assistant.

If the issue persists, please attach a new sysdiagnose captured in the latest build and attach it to the bug report. Thank you.

iOS sysdiagnose Instructions:

For a complete list of logging instructions visit:

We appreciate your feedback and looking forward to hear from you.

By at April 19, 2024, 6:18 a.m.

Open Radar FB13406194: `DisclosureGroup` does not animate `isExpanded` binding update when inside a `List`


Thanks for looking into it! Looking forward to the long-term solution.

By at April 19, 2024, 6:17 a.m.

Open Radar FB13406194: `DisclosureGroup` does not animate `isExpanded` binding update when inside a `List`


We examined your provided project and did find the difference between macOS and iOS, and it will be addressed in future. For a workaround, please update your binding to the DisclosureGroup from isExpanded: $isExpanded to isExpanded: $isExpanded.animation(), so that the DisclosureGroup will be forced to update the state with animation, and it will let List/DisclosureGroup on macOS behave as the same as iOS

Also just to be clear - the iOS side also does not animate row sizes, it only animate the text size, so it has the same issue of text ‘jumping’

By at April 19, 2024, 6:16 a.m.

Open Radar FB13723251: UIDropSession.canLoadObjects(ofClass: NSItemProviderReading) not working correctly when using Universal Control in iOS 17


For now you can replace these:

session.canLoadObjects(ofClass: aClass)


session.hasItemsConforming(toTypeIdentifiers: aClass.readableTypeIdentifiersForItemProvider)

By victor.pimentel at April 12, 2024, 8:52 a.m.

Open Radar FB13723251: UIDropSession.canLoadObjects(ofClass: NSItemProviderReading) not working correctly when using Universal Control in iOS 17


<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> <key>UIApplicationSceneManifest</key> <dict> <key>UIApplicationSupportsMultipleScenes</key> <false/> <key>UISceneConfigurations</key> <dict> <key>UIWindowSceneSessionRoleApplication</key> <array> <dict> <key>UISceneConfigurationName</key> <string>Default Configuration</string> <key>UISceneDelegateClassName</key> <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string> <key>UISceneStoryboardFile</key> <string>Main</string> </dict> </array> </dict> </dict> <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.composite-content</string> </array> <key>UTTypeDescription</key> <string>Example Document</string> <key>UTTypeIconFiles</key> <array/> <key>UTTypeIdentifier</key> <string>com.example.mydocument</string> <key>UTTypeTagSpecification</key> <dict/> </dict> </array> </dict> </plist>

By victor.pimentel at April 12, 2024, 8:47 a.m.

Open Radar FB13723251: UIDropSession.canLoadObjects(ofClass: NSItemProviderReading) not working correctly when using Universal Control in iOS 17


import UIKit

class ViewController: UIViewController, UIDropInteractionDelegate {

override func viewDidLoad() {

    let interaction = UIDropInteraction(delegate: self)

func dropInteraction(_ interaction: UIDropInteraction, canHandle session: UIDropSession) -> Bool {

func dropInteraction(_ interaction: UIDropInteraction, sessionDidUpdate session: UIDropSession) -> UIDropProposal {
    UIDropProposal(operation: .copy)

func dropInteraction(_ interaction: UIDropInteraction, performDrop session: UIDropSession) {
    if session.canLoadObjects(ofClass: ExampleProviderReading.self) {
        print("Can load objects")
        session.loadObjects(ofClass: ExampleProviderReading.self) { containers in
            guard let container = containers.first as? ExampleProviderReading else {
                fatalError("[BUG] Could not load object!")
            print("Loaded an object: \(container)")


final class ExampleProviderReading: NSObject, NSItemProviderReading { static var readableTypeIdentifiersForItemProvider: [String] { return ["com.example.mydocument"] }

static func object(withItemProviderData data: Data, typeIdentifier: String) throws -> ExampleProviderReading {


By victor.pimentel at April 12, 2024, 8:45 a.m.

Open Radar 10257191: NSPipe/NSFileHandle file descriptors never freed

SourceTree still broken...

It's April 2024 and I've just seen this error for the first time, using SourceTree 4.2.7 on a Mac OS Sonoma 14.4.1.

By daviddiazgarcia at April 10, 2024, 10:58 a.m.

Open Radar FB13557971: mDNSResponder incorrectly appends search domain to expired CNAME requests with AlwaysAppendSearchDomains

Reply from 'Apple Feedback':

There are changes in the latest update, build 23F5049f, that may have resolved this issue. You can see the software build your device is running and check for the latest update by clicking on the Apple logo in the upper left hand corner > About This Mac. If the build is not visible, click on the macOS version, e.g. 10.15.x, to reveal it.

Has this issue been resolved after installing the latest update? If not, please use Feedback Assistant to let us know you are still experiencing it.

By robertof.public at April 5, 2024, 8:39 a.m.

Open Radar FB13701617: Push Notifications Delivery


This is also impacting background notification deliveries for CloudKit running on iOS and macOS.

Open Radar FB13701617: Push Notifications Delivery


Upon further inspection:

  • Toggling the WiFi on/off on the device does has no affect.

  • Toggling iCloud Private Relay momentarily works, push notifications arrive, then stop again with the same error.

  • Toggling iCloud Private Relay off again momentarily works.

Furthermore, the apn-unique-id header value in responses cannot be looked up in the Push Notifications console, when the payload is sent to APNS from a script.

Open Radar FB13687535: Environment objects injected on a TabView that contains a NavigationStack never deallocate

Contents of the attached sample project:

@main struct MemoryLeakDemoApp: App { var body: some Scene { WindowGroup { ContentView() } } }

struct ContentView: View {

@State private var showsNavstack = true

var body: some View {
    if showsNavstack {
        LeakyView(isDisplayed: $showsNavstack)
    } else {

init() {
    #warning("comment this out to exhibit another leak")


struct LeakyView: View {

@Binding var isDisplayed: Bool
@StateObject private var canary = Canary()

var body: some View {
    // If the navstack is not embedded in a tab view (directly or indirectly), neither leak gets triggered
    TabView {
        NavigationStack {
            ScrollView {
                VStack(spacing: 16) {
                    Text("Scroll me **up and down**")
                    Button("Then Hide Me") { isDisplayed = false }
                .frame(minHeight: 500)
            // THIS CAUSES ONE OF THE LEAKS – somehow only triggered after scrolling the content a bit
            // However the navbar is also hidden automatically because there's no nav title
            .toolbar(.hidden, for: .navigationBar)


struct CheckerView: View {

@State private var text = ""

var body: some View {
    VStack(spacing: 16) {
        Button("Check Canary") {
            if Canary.instance == nil {
                text = "Canary is dead ✅"
            } else {
                text = "Canary is still alive ❌"

        Button("Trigger a Workaround") {
            text = "Check again now ⬆️"


final class Canary: ObservableObject {

private(set) static weak var instance: Canary?

init() {
    Self.instance = self


/// As of iOS 13-17.2 (and likely in newer versions too), SwiftUI environment (both values and objects) applied to a TabView that contains a NavigationView/Stack leaks due to being injected into a UIKit trait collection of the underlying navigation controller, which then gets captured by: /// - A UILabel cached globally by UINavigationBar for the purposes of large title label measurement (only if it's the first navigation bar created in the entire app). /// - A pointer interaction's helper view that gets registered with the window by UINavigation but never deregistered. /// Members of this extension work around these leaks. extension UIApplication {

/// This method works around the memory leak caused by the global `UILabel` by creating a dummy navigation bar and triggering a layout pass on it, which forces the label to be created (via function `_UINavigationBarLargeTitleViewLabelForMeasuring`). This prevents navigation bars created _later on_ from capturing the real trait environment, which includes the SwiftUI environment.
/// In order to be effective, this method must be called early on in the application lifecycle, before any navigation views are created, but after at least one window scene has been created.
static let inoculateAgainstSwiftUIEnvironmentMemoryLeakType1: Void = {
    guard let scene = shared.windowScene else {
        assertionFailure("Can't work around the memory leak: no window scenes connected")

    let bar = UINavigationBar(frame: CGRect(x: 0, y: 0, width: 320, height: 88))
    bar.prefersLargeTitles = true

    let item = UINavigationItem()
    bar.pushItem(item, animated: false)

    let window = UIWindow(windowScene: scene)


    // The window is removed from the scene automatically as it deallocates

/// This method works around the memory leak caused by a leftover pointer interaction still registered in the window after the navigation bar deallocates.
/// Navigation bar creates one or more `_UIPointerInteractionAssistant` (subclass of `UIPointerInteraction`) objects, which are registered with the window. `_UIPointerInteractionAssistantEffectContainerView`, owned by each interaction, is a subview of the navigation bar, and thus captures the trait collection from it. Normally, these interactions get deregistered from the window as the navigation bar goes off-screen, but sometimes they're not, which leaks the SwiftUI environment as the trait collection stored in the view outlives its superview. This is generally triggered by showing/hiding the navigation bar as part of a push/pop.
/// In order to avoid unintended side effects, this method must only be called while there's no important UI on the screen.
static func workAroundSwiftUIEnvironmentMemoryLeakType2() {
    for window in shared.windowScene?.windows ?? [] {
        workAroundSwiftUIEnvironmentMemoryLeakType2(in: window)

private static func workAroundSwiftUIEnvironmentMemoryLeakType2(in window: UIWindow) {
    // UIWindow holds "subtree monitors" – including _UIPointerInteractionAssistant objects (a UIPointerInteraction subclass) – in a nullable NSMutableSet ivar called _subtreeMonitors. It's modified in two methods: _registerSubtreeMonitor and _unregisterSubtreeMonitor. We use the latter to unregister all monitors of the pointer interaction class, thus hopefully removing the only remaining references to them.
    let selector = Selector(("_unregisterSubtreeMonitor:"))
    let ivar = class_getInstanceVariable(UIWindow.self, "_subtreeMonitors")!
    let monitors = object_getIvar(window, ivar) as! NSSet?

    // Remove all monitors of the relevant class
    for case let monitor as UIPointerInteraction in monitors ?? NSSet() {
        window.perform(selector, with: monitor)


// MARK: - Private extensions

private extension UIApplication {

var windowScene: UIWindowScene? {
    connectedScenes.compactMap { $0 as? UIWindowScene }.first


By argentumko at March 15, 2024, 4:45 a.m.

Open Radar FB10500605: Write to system register S3_6_C15_C1_5 (aka. SPRR_PERM_EL0 ) in pthread_jit_write_protect_np can fail rarely

It got fixed in macOS 13.0 Beta 3 (22A5295i) and was a race in the process setup by the kernel.

Some hints can be found in a XNU source bump: