Hello,

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 https://feedbackassistant.apple.com/ or by using the Feedback Assistant app.

iOS 17.5 beta (Build: 21F5048f) https://developer.apple.com/download/ 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: https://developer.apple.com/services-account/download?path=/iOS/iOS_Logs/sysdiagnose_Logging_Instructions.pdf

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

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

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’

Issue still exists in Xcode 15.3 and iOS 17.4

For now you can replace these:

session.canLoadObjects(ofClass: aClass)

With:

session.hasItemsConforming(toTypeIdentifiers: aClass.readableTypeIdentifiersForItemProvider)

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <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>

import UIKit

override func viewDidLoad() {
    super.viewDidLoad()

    let interaction = UIDropInteraction(delegate: self)
    view.addInteraction(interaction)
}

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

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)")
        }
    }
}

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

}

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.

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.

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

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.

Me too ... fairly consistently disconnects after 48 minutes.

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 {
        CheckerView()
    }
}

init() {
    #warning("comment this out to exhibit another leak")
    UIApplication.inoculateAgainstSwiftUIEnvironmentMemoryLeakType1
}

}

struct LeakyView: View {

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

var body: some View {
    // THIS CAUSES THE LEAKS
    // 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)
        }
    }
    // THIS LEAKS THE CANARY
    .environmentObject(canary)
}

}

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 ❌"
            }
        }
        Text(text)

        Button("Trigger a Workaround") {
            UIApplication.workAroundSwiftUIEnvironmentMemoryLeakType2()
            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")
        return
    }

    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)
    window.addSubview(bar)

    bar.layoutIfNeeded()

    // 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) {
    // WARNING: THIS IS PRIVATE API
    // 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
}

}

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: https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/bsd/kern/kern_exec.c#L4081-L4099

Fixed in normal release

See http://www.openradar.me/FB13619556

Fixed.

Yep, this is still an issue with 14.3. My last reply from Apple in January about this issue suggested it could be a performance issue with my MEMessageSecurityHandler extension but this definitely happens with Apple's sample extension code.

_lineHeightMultiple is available as an environment key, so environment(._lineHeightMultiple) helps in iOS 17.

Still would love to have an option for negative space

There's also a tangential issue where there is no support for VBR Opus whatsoever -- people tend to make them because opusenc makes them by default. As a result, you can't just remux to caf, but you need to also do an actual re-encode in CBR. (FFmpeg will gladly make a CAF with VBR Opus. It just won't play.)