I'd like to know more about this. I have a QOS_CLASS_USER_INTERACTIVE queue dedicated to AVAudioEngline calls. Seems to work fine thus far but I do get this warning on a call to [engine connect:playerNode to:engine.mainMixerNode format:buffer.format]; [Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions. If I change the queue priority to default the warning goes away but the higher QOS seems more appropriate for the task?

Hi, I think we should continue this with https://feedbackassistant.apple.com - please can you attach a minimal project and image that replicates the issue. I already filed FB15114920. In that sample I just loaded the CMYK image using NSBitmapImageRep...if I remember correctly. But if you use that same source image in that sample project and try use the Accelerate APIs to convert it to RGB you'll get the same black box NSBitmapImageRep gives you.

Third time is the charm. Finally went through...

I filed FB15777063

In addition to the Feedback, I opened a TSI on this at the end of September. I haven't heard back. Is this considered a bug or not? I can't think of any reason why the behavior I described would be intentional but if it is intentional I do think there should be a way for developer to opt out.

This was an intentional change in macOS Sequoia to limit the ability of key-logging malware to observe keys in other applications. The issue of concern was that shift+option can be used to generate alternate characters in passwords, such as Ø (shift-option-O). There is no workaround; macOS Sequoia now requires that a hotkey registration use at least one modifier that is not shift or option. I don't understand this explanation at all. Why wouldn't you just not dispatch keyboard events when the user is interacting with password related UI? For example if an NSSecureTextField is editing in the active app...just don't post the keyboard event to listeners. When the user is not interacting with password related UI let them trigger their keyboard shortcuts because....that's what they actually want to do.

Also noticed that option-clicking on a method no longer brings up documentation in the popover for everything in Foundation. For example if I option click on a method call on NSString: -componentsSeparatedByString: The popover shows me no documentation at all (just the method name, which I already know). There is a link to the header file which I can click but the header file has no comments. So no documentation at all. All I get is the method name now. In the menu bar I can go to: Window -> Documentation and search for it....but this is really quite a step backwards. These Swift rewrites are just wonderful.

Ahh yeah duh. Got too many windows open...doing too many things at once, skimmed the text too quickly. Will put it off til my next update then, which will come before February.

Okay, I don't care about "the best" extension, I care about ones, which do the job they're intended to do. Yea I mean, that's an opinion. So much archived documentation. Think this thread got a little off-topic from the initial reported issue. >Recent Similar Reports: Less than 10 >Resolution: Potential fix identified - For a future OS update This sounds encouraging, I only wonder what a "potential fix" really means, how huge that potential is? Yeah I don't understand why they have to speak to us in riddles. They either added the section back in System Settings and it'll be fixed in the next update, or they did not. There is not really anything in between here (though I recognize in more complicated cases you may not know with 100% certainty whether a bug is fixed or not). I don't see a fix mentioned in the Beta release notes, though. So now, according to the Apple Store Connect reviewer, the Finder Sync extensions settings missing from System Settings in Sequoia is a bug in MY application! Ouch. It's been hard lately to get maintenance updates through App Review on the Mac App Store lately. Extremely frustrating. It's a real bummer when you hit a system bug that blocks you from doing what you need/want to do and you have no idea if/when they'll ever fix it. Some bugs are so bad you'd assume they just fix them right away but you would often be wrong. They broke AVSpeechSynthesizer in iOS 17 and never fixed it (maybe they did in iOS 18 but I don't think I want to use that API anymore..given how they treated apps using it). I thought for sure they'd fix AVSpeechSynthesizer quickly because so many apps use it, but they didn't. Never got a response back on my bugs. TSI quickly got shut down with "no workaround available." A similar story. I got plenty of stories. You'd think a change that removes an entire preferences section would be easy to revert and would be fixed quickly. You got apps in the Mac App Store now that when purchased, can't work. Apple hasn't pulled all the Finder Extension apps from the Mac App Store. Presumably a bug that would cause users to purchase a non-functioning app (on Sequoia) at no fault to the developer would be considered a priority. If we added the total downloads of every app on the Mac App Store together we're still probably less than Facebook so our prospects are looking pretty grim here.

This logs out when I try to redeem the code. AMSURLSession: [] Task completed with error = Error Domain=AMSErrorDomain Code=301 "Invalid Status Code The response has an invalid status code" UserInfo={AMSDescription=Invalid Status Code, AMSStatusCode=500, NSDebugDescription=Invalid Status Code The response has an invalid status code, AMSFailureReason=The response has an invalid status code, AMSURL=h t t p s://someurl-buy.itunes.apple.com/commerce/redeemCodeSrv?guid=somenumber}

FB15493942

Workaround: In New Xcode Project....delete the top level blue folder (the parent folder that contains AppDelegate.m, etc.) and all starter files. When deleting choose Remove References only. Then drag and drop the folder back into your Xcode project. Choose for Action-> Reference Files in place. Choose for Groups -> Create Groups (not folder references). Once you have a "Group Reference" you can drag and drop reorder, create new groups without folders, etc. just like you could before. Actually a better way to get desired behavior is to right click on the folder and choose "Convert to Group." I'm not sure why this change was made but I'd always want a "Group" over a "Folder" so I can reorder right in Xcode.

Like @mike I do appreciate your response. I especially appreciate your other responses on several issues on other posts and to me specifically in an DTS incident. I think it helps us all become better developers (we all don't have degrees from Stanford after all). I did have a few knee-jerk reactions reading some of the responses here. I decided to take a deep breath and think on it a bit before replying. I appreciate that you confirmed the original issue reported here (that the "Finder Extensions" section has completely disappeared from System Settings) is indeed a bug and not intended behavior. This was done without prior warning. If you do deprecate an API without introducing a feature equivalent replacement, this isn't the way to do it. I think it is reasonable that others inquired about the future of Finder Extensions in response to all this. I don't think it is particularly helpful to point out that the intended use of an API is not what Apple expected. I know you probably didn't mean it that way but when you read it, it could feel like a cop out. "You were holding it wrong the entire time, so if the section in Systems Settings disappears that's on you." Again I don't think that's how YOU intended it to come across. But that's how developers could feel, reading it (at least initially). I think you were recommending that you move to a newer API (which if we could, we would but that newer API doesn't support what we are doing). I consider App Development to be a creative field and I think you touched on this in your previous post. The fact that developers are quick to ask if this bug is a sign of future deprecation speaks to the fact that they have probably been burned before. Apple has to focus on how an issue impacts users, not individual apps. A bug that breaks 1 app with 100 million users is a much bigger problem (for us) than a bug that breaks 100 apps with 100,000 users. This makes a lot of sense. We all have to prioritize issues and user impact is very important. However, I've reported countless bugs over the years (many of which are low-hanging fruit which you should be able to fix in 15 minutes but often never get fixed). While I don't have 100 million users, I imagine that such low hanging fruit impacts a lot of regular users across many apps (many of whom don't even know how to report bugs to Apple). You can't reasonably expect us to keep filing bugs if you seem to never fix them, at least not in a timely manner (presumably because we don't have millions of users).

Updating the arrays won't cause the table view to automatically update as well. You need to tell the table view. Use the following methods: // Inserts a new rows located at the final positions passed to by 'indexes'. This is similar to NSMutableArray's -insertObjects:atIndexes: The -numberOfRows in the TableView will automatically be increased by the count in 'indexes'. Calling this method multiple times within the same beginUpdates/endUpdates block is allowed, and changes are processed incrementally. This method should not be called for NSOutlineView (use -insertItemsAtIndexes:inParent:withAnimation: instead). The "Cell Based TableView" must first call -beginUpdates before calling this method. This method can also be used when "usesStaticContents=YES". - (void)insertRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)animationOptions API_AVAILABLE(macos(10.7)); /* Removes a row currently at each row in 'indexes'. This is similar to NSMutableArray's -removeObjectsAtIndexes:. The row indexes should be with respect to the current state displayed in the TableView, and not the final state (since the rows do not exist in the final state). The -numberOfRows in the TableView will automatically be decreased by the count in 'indexes'. Calling this method multiple times within the same beginUpdates/endUpdates block is allowed, and changes are processed incrementally. This method should not be called for NSOutlineView (use -removeItemsAtIndexes:inParent:withAnimation: instead). The "Cell Based TableView" must first call -beginUpdates before calling this method. This method can also be used when "usesStaticContents=YES". */ - (void)removeRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)animationOptions API_AVAILABLE(macos(10.7)); /* Moves a row from the prior 'oldIndex' to 'newIndex' in an animated fashion (if needed). This is similar to removing a row at 'oldIndex' and inserting it back at 'newIndex', except the same view is used and simply has its position updated to the new location. This method can be called multiple times within the same beginUpdates/endUpdates block. This method should not be called for NSOutlineView (use -moveItemAtIndex:inParent:toIndex:inParent: instead). The "Cell Based TableView" must first call -beginUpdates before calling this method. This method can also be used when "usesStaticContents=YES". */ - (void)moveRowAtIndex:(NSInteger)oldIndex toIndex:(NSInteger)newIndex API_AVAILABLE(macos(10.7)); /* View Based TableView: API to hide and unhide rows. Sometimes, it is better or easier to simply hide a row instead of permanently removing it from the table. Hiding it allows the model to not change, but the UI to appear as though it doesn't exist. Hidden rows will have a zero height, and not be selectable by the user (but can still be programmatically selected). Be aware that hiding a selected row will leave it selected. Hiding a row will call the delegate methods tableView:didRemoveRowView:forRow:, and unhiding will subsequently call tableView:didAddRowView:forRow:. */ - (void)hideRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)rowAnimation API_AVAILABLE(macos(10.11)); - (void)unhideRowsAtIndexes:(NSIndexSet *)indexes withAnimation:(NSTableViewAnimationOptions)rowAnimation API_AVAILABLE(macos(10.11)); And there is also -reloadData https://developer.apple.com/documentation/appkit/nstableview/1528382-reloaddata?language=objc and -reloadDataForRowIndexes:columnIndexes: https://developer.apple.com/documentation/appkit/nstableview/1527621-reloaddataforrowindexes?language=objc

If you view the original post this answer looks like it's the accepted answer (I don't think the OP marked it as the accepted answer). But it looks that way and is badged "Apple recommended." Since this suggestion didn't work the answer shouldn't be pinned to the original post and badged Apple recommended IMO.