dsym file

I have a view that conforms to DropDelegate. When a file is dragged from the Finder and dropped on the view, the performDrop(info:) method successfully extracts a URL from the item provider and returns true, but the drag image slides away as if the drop had been rejected. Why? func performDrop(info: DropInfo) -> Bool { bgColor = .yellow let providers = info.itemProviders(for: [.fileURL]) print(performDrop, providers: (providers.count)) if let aProvider = providers.first { if aProvider.hasItemConformingToTypeIdentifier(UTType.url.identifier) { aProvider.loadItem(forTypeIdentifier: UTType.url.identifier) { (item, error) in if let error = error { print(Error retrieving item provider data: (error.localizedDescription)) return } if let url = item as? URL { print(Received file URL (from Data.1): (url)) } else if let data = item as? Data, let url = URL(dataRepresentation: data, relativeTo: nil) { print(Received file URL (from Data.2): (url)) } } } } return true }

Environment: macOS 26.2 (Tahoe) Xcode 16.3 Apple Silicon (M4) Sandboxed Mac App Store app Description: Repeated use of VNRecognizeTextRequest causes permanent memory growth in the host process. The physical footprint increases by approximately 3-15 MB per OCR call and never returns to baseline, even after all references to the request, handler, observations, and image are released. ` private func selectAndProcessImage() { let panel = NSOpenPanel() panel.allowedContentTypes = [.image] panel.allowsMultipleSelection = false panel.canChooseDirectories = false panel.message = Select an image for OCR processing guard panel.runModal() == .OK, let url = panel.url else { return } selectedImageURL = url isProcessing = true recognizedText = Processing... // Run OCR on a background thread to keep UI responsive let workItem = DispatchWorkItem { let result = performOCR(on: url) DispatchQueue.main.async { recognizedText = result isProcessing = false } } DispatchQueue.global(qos: .userInitiated).async(execute: workItem) } pr

macOS 26 Tahoe is allocating much more memory for apps than former macOS versions: A customer contacted me with my app's Thumbnail extension allocating so much memory that her 48 GB RAM Mac Mini ran into out of application memory state. I couldn't identify any memory leak in my extension's code nor reproduce the issue, but found the main app allocating as much as 5 times the memory compared to running on macOS 15 or lower. This productive app is explicitly using Liquid Glass views as well as implicitly e.g. for an inspector pane. So I created a sample app, just based on Xcode's template of a document-based app, and the issue is still showing (although less dramatically): This sample app allocates 22 MB according to Tahoe's Activity Monitor, while Sequoia only requires 16 MB: macOS 15.6.1 macOS 26.2 Is anyone experiencing similar issues? I suspect some massive leak in Tahoe's memory management, and just filed a corresponding feedback (FB21967167).

Hi, I’m trying to understand the correct process for Apple Developer Program organization enrollment when identity verification cannot be completed due to an outdated passport photo. Based on our last communication, I believe the enrollment was paused/declined because my passport photo didn’t match my current appearance (I’m assuming this because the last communication we had was specifically about my passport photo). I have since obtained a new passport with an updated photo. Timeline for context: • Jan 9: My enrollment was put on hold / could not proceed after ID verification. • Jan 12: I applied for a new passport with an updated photo. • After receiving the new passport, I followed up to provide the updated ID, but I’m not sure what the correct next step is in the enrollment workflow. Could you please advise the recommended way to proceed? • Should I submit a new organization enrollment, or can the existing one be re-opened/continued? I couldn’t find a way to resubmit/continue the existing enrollment from

We are currently testing our application under macOS 26 in Liquid Glass mode and noticed an issue with NSSegmentedCell. Our app makes extensive use of NSCell-based drawing. Since macOS 26, when running in Liquid Glass mode, NSSegmentedCell does not render at the expected location. The control itself appears visually correct, but it is clearly drawn offset from the rect it is supposed to occupy. In compatibility mode, everything renders exactly as expected (same code, same layout). To illustrate the issue, here are two screenshots of the same view: Liquid Glass mode 👉 (screenshot 1 – segmented control visibly shifted) Compatibility mode 👉 (screenshot 2 – correct rendering) The regression is obvious when switching between the two modes. This behavior has been present since the first macOS 26 release and is still reproducible with Xcode 26.2 (17C52). I have already filed a report via Feedback Assistant (FB reference available if useful), but I’m posting here to see whether others are experiencing the