Feedback report submitted (FB25296814)

I forgot to mention that the lightweight migration succeeded on iOS 18 - the corresponding statement logged without error as below: CoreData: annotation: Executing entity schema & data migration statement: NSSQLiteStatement <0x600002150af0> on entity '(null)' with sql text 'ALTER TABLE Z_5MATERIALS RENAME COLUMN Z_5LISTS4 TO Z_5LISTS5'

Any news on this one? I'm facing a very similar issue with Xcode Version 27.0 (27A266a) after adding a single boolean attribute to an entity "List". The lightweight migration is triggered and fails with in incorrect column name in a "ALTER TABLE" statment: CoreData: annotation: Begin entity schema & data migration statements. CoreData: annotation: Executing entity schema & data migration statement: NSSQLiteStatement <0x106e4ef80> on entity 'List' with sql text 'ALTER TABLE ZLIST ADD COLUMN ZQUERYSUMQUANTITIES INTEGER' CoreData: annotation: Executing entity schema & data migration statement: NSSQLiteStatement <0x106e4efd0> on entity '(null)' with sql text 'ALTER TABLE Z_5MATERIALS RENAME COLUMN Z_5LISTS4 TO Z_5LISTS5' no such column: "Z_5LISTS4" in "ALTER TABLE Z_5MATERIALS RENAME COLUMN Z_5LISTS4 TO Z_5LISTS5" Actually, I don't understand where the second "ALTER TABLE" statement is coming from, as no changes were done to any relationships...

+1 ... Apple, any plans to fix this? I'm already dropping iOS 16 support due to missing simulator support. Feedback ID: FB24922032 Edit: I found this communicated in Xcode 27 Release Notes - and unfortunately still in Beta 2: Keyboard and mouse inputs to simulators for OS versions before iOS 18.0, tvOS 18.0, watchOS 11.0, and visionOS 2.0 are not accepted. (181945323)

More than 7 years later and the issue still exists - even with Preview / Thumbnail extensions: NSFileCoordinator / NSFilePresenter are used (and working with the apps on macOS and iOS), but Console.app is reporting a sandbox violation once a file with related items ("sidecar files") is previewed. Unfortunately, no comment from Apple at all, not even a "works as designed" - what would be strange as the behavior was broken with macOS 10.15...

I hadn't checked for a while, but when updating the corresponding app with macOS / Xcode 26.2 I found this issue fixed - nothing stated in any release note I browsed.

I just attached an allocation trace to the FB I run with my productive app on macOS 26.2. "Instruments" is showing a peak of 128 MB allocated memory, while "Activity Monitor" is showing approx. 50 MB on macOS 15. Unfortunately, I wasn't able to collect a similar allocation trace with macOS 15.6.1: It's running in a VM, and due to restrictions of virtual machines I cannot register my Apple development account for proper application signing - but I'm happy to go this extra mile if DTS was able to provide related instructions. Looking forward to any response in the ticket...

What I just forgot: In the FB ticket I mentioned the Apple ID of my productive app, so you could just run the app under Sequoia and Tahoe ... unfortunately it is way too complex to act as a sample app (that's why I was additionally providing the minimal app with a less dramatic result)...

Hi Albert, Thanks for your swift reply! I had used Instruments to analyze the app's memory allocations and releases without identifying any significant memory leak (under macOS 26). I'm happy to dive deeper supply an Instrument trace in the corresponding ticket, these days. On the macOS 15 virtual machine, Xcode / Instruments is not installed, but honestly I expect other developers to have similar observations, and I'm not talking about some minor increase, but (in my productive app) by five times... Regarding the mentioned consumption by Thumbnail - which was way beyond any justified memory allocation: I could neither reproduce the customer's issue, nor debug / analyze app's Preview / Thumbnail extensions (actually I filed a corresponding DTS ticket): Without "qlmanage" to work for modern extensions, Xcode is not properly attaching the running extension to the Finder - or is just me, missing some concrete instructions (what I asked for in the DTS request). Don't get me wrong, I'm willing to provide more information if / when my time allows, but it honestly looks like Tahoe has some serious memory management issues, and I'd appreciate your teams taking developer's feedback as a call for action...

Good news: The issue "NSRulerView is obscuring content in full screen" seems to be fixed with macOS 26.2 Beta. Thanks for the feedback on my bug report, Apple team! ☺️

I'm still unsure if the different color of horizontal ruler views is a bug or the intended design under macOS 26. Therefore, I filed a DTS incident (Apple Developer Technical Support, TSI), asking for a way to customize an NSRulerView's background color...

Okay, let's try to sort this out a bit - I was confused facing a couple of different issues: NSRulerViews are showing inconsistent Backgrounds: With macOS 26 NSRulerViews are showing a very different layout, not only in contrast to prior macOS versions, but also inconsistent between horizontal and vertical rulers. I filed a corresponding bug report (FB20342342) The horizontal ruler view is showing with a solid color. I assume the color is selected based on the first line of the inner view, because with a transparent content view the scrollview's background color is used, otherwise the content view's background color. The vertical ruler view is using a much lighter or transparent version of the content view's background, what I would consider the intended (and expected) behavior. NSRulerView is obscuring content in full screen: Custom apps are facing an incorrect behavior of NSRulerViews when running in full screen: The height of the horizontal ruler is increased, obscuring the top of the clipview. I observed this issue with one of my apps, but was able to replicate it with a minimal sample app, using a scrollable text view with rulers, refer to the attached screenshots. Again, I files a bug report (FB20342122) Window mode: Full Screen:

Hi Quinn! That's what I did and ... surprise! Thank you!

Unfortunately, the filed bug report was not acknowledged by Apple - it is still open, no feedback or status report was given, and macOS 26 "Tahoe" was shipped with the very same issue. @DTS Engineer : Quinn, you should know that I value your contributions in this forum the highest ... but I see a pattern when looking at my bug reports: After migrating from RADARs to the Feedback Assistent, almost all of them are lacking substainable feedback by Apple. Maybe something you can address internally...?

Of course I was referring to "squircles" ... my bad!