I'm facing the same problem as addressed in this discussion: After switching from legacy QLGenerators to Preview extensions on macOS I cannot debug the extensions' code in Xcode, anymore: I launch the app with the embedded appex from Xcode in debug mode. When trying to attach to the appex process the following error is reported: Code: 6 Failure Reason: Ensure “AppName Preview” is not already running, and matthias has permission to debug it. User Info: {... } System Information macOS Version 15.4.1 (Build 24E263) Xcode 16.3 (23785) (Build 16E140) Timestamp: 2025-05-12T14:07:14+02:00 I'm using a standard user account (no admin) and might miss some obvious steps. Can someone detail the steps to debug a Preview (or Thumbnail) extension with Xcode 16? For legacy Quick Look plugins I was using "qlmanage", but that's not working on extensions. All the best, Matthias P.S.: Pardon me re-posting my reply as a separate thread, to increase visibility, but I'm quite desperate and couldn't find any solution on the web...

Hi all, I have repeatedly the issue that a certain .strings file in my app's bundle has the extended files attribute com.apple.quarantine set. Consequently the submission fails with the following mail notification: We noticed one or more issues with a recent delivery for the following app: [...] ITMS-91109: Invalid package contents - The package contains one or more files with the com.apple.quarantine extended file attribute, such as “abcdef.strings”. This attribute isn’t permitted in macOS apps distributed on TestFlight or the App Store. Please remove the attribute from all files within your app and upload again. I'm able to resubmit the bundle after cleaning the file attribute via xattr -d -r com.apple.quarantine..., but the funny thing is it happens again and again - on a .strings file which hasn't been downloaded (but manually created), shouldn't be under Gatekeeper's quarantine, and wasn't edited in the meantime. Is anybody else observing the same issue with macOS 15.4.1, Xcode 16.3? Greetings, Matthias

NSToolbar items don’t react to Dark Mode changes in apps compiled with macOS 15 SDK: My app was installed as a notarized app on a Tahoe VM with the same build as distributed in the App Store, based on macOS 15 SDK. When toggling Dark Mode, toolbar items are not updated, but only after opening a new window / tab or e.g. customizing the toolbar. The app is using default methods for the toolbar, defined in its corresponding XIB file, and working in previous macOS versions. This issue could be confirmed with various apps built with an SDK prior to macOS 26 "Tahoe", e.g. Apple's Clipboard Viewer. Reported via Feedback Assistent (FB19107572).

Just posted this feedback regarding macOS 26 "Tahoe" (FB19853155) - please support with additional submissions if you share my view. I will miss the beautiful and individual designed icons of the past! "macOS 26 is enforcing squicles for app icons, falling back to a grey background for 3rd party apps without a compliant AppIcon asset. As a result many original app icons are reduced in size and hard to distinguish because they share the same background color. Although I respect Apple's strive for an iOS-like UI on Macs, a smooth transition path would be more user- and developer-friendly ... e.g. with some info.plist property to opt-out icon migration, potentially ignored by a future macOS version. The current solution causes a bad usability, and makes the system look inconsistent as many - especially free - software will not be updated with new icon designs. Please reconsider this bad design decision!"

After installing my notarized 3rd party app in a Tahoe VM, its embedded Automator actions can not be configured in Automator while defining a workflow: After adding the actions (enabling 3rd party extensions), their views / UI elements do not respond to any mouse event. When enabling „show this action when running“, the options can be changed during execution of the workflow. Needless to say: Adjusting these action settings in Automator was working for years, macOS 12 - 15 and before. Reported via Feedback Assistent (FB19015185). Can anybody confirm this issue with Automator actions?

When disabling the opacity slider of color panels, my app crashes with unsatisfiable layout constraints. Feel free reproduce with a minimal test project: A macOS app based on the Xcode 26.0 template with only one line added to the ViewController's viewDidLoad() function: NSColorPanel.shared.showsAlpha = false The issue doesn't occur if this property is set to "true" or not set at all. I just filed a corresponding bug report (FB20269686), although I don't expect any feedback from Apple ... as numerous issues I reported were never updated or commented at all (after migrating from RADARs).

When I compiled my legacy project with Tahoe's macOS 26 SDK, NSRulerViews are showing a very different design: Under prior macOS versions the horizontal and verrical ruler's background were blurring the content view, which was extending under the rulers, showing through their transparency. With Tahoe the horizontal ruler is always reflecting the scrollview's background color, showing the blurred content view beneath. And the vertical ruler is always completely transparent (without any blurring), showing the content together with the ruler's markers and ticks. It's difficult to describe, I'll try to replicate this behavior with a minimal test project, and probably file a bug report / enhancement request. But before I take next steps, can anyone confirm this observation? Maybe it is an intentional design decision by Apple?