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.

@milke Indeed. I just wanted to add how I'm using pluginkit in an app outside the Mac App Store since Kevin made this point about pluginkit when asked if it was a valid workaround: Yes and no. A few different points to be aware of: It's certainly not something I would assume will work >"forever" and architect your app around. I use pluginkit, and have been for years for the reason I described in my previous post. It wouldn't be good for devs if they deprecated it without replacing it with something that could achieve equivalent functionality. I just wanted to put that out there in the universe. As far as my sandboxed Mac App Store Finder extensions go, there is no workaround and I'm in the same boat as everyone else. I can only explain to users how to enable the extension in Terminal or recommend the FinderSyncer app (or write my own which I do not want to spend time doing right now). Should the original answer recommending https://developer.apple.com/documentation/extensionkit/exappextensionbrowserviewcontroller?language=objc be unmarked as the Apple recommended correct answer in this thread?

I have a few Finder extension apps. None of them do any kind of syncing. All of them add actions to Finder via a custom toolbar button and/or context menu items. It's been a long time and I do remember them being introduced as "Finder Sync Extensions." At some point I thought they were renamed to "Finder Extensions." I still have a Mac running macOS Monterey and in System Preferences the section is called "Finder Extensions" not "Finder Sync Extensions." My interpretation of this was that this was an acknowledgement that these extensions may not be related to syncing (and do not necessarily have to be related to syncing). I do hope I'm not wrong about that, being that there are so many "Finder extensions" like this on the Mac App Store that were approved. Just to chime in as far as pluginkit goes, I have an outside the Mac App Store app that has been using this for years to re-enable a Finder extension after a software update (if the extension was enabled prior to updating) because a software update would cause the extension to automatically disable after the app was replaced (forcing the user to go back into Settings). So pluginkit in my case was needed to avoid customer support emails like "I updated the app and now the Finder extension is broken). PluginKit doesn't help Mac App Store / sandboxed apps though as already mentioned but hopefully pluginkit won't be removed because it still serves a purpose... Far as my Mac App Store sandboxed apps go, I had them all enabled before updating to Sequoia and they still appear and work. But new customers purchasing on Sequoia can't enable them? And existing customers that had them enabled can't disable them unless they are wizards and know how to use pluginkit from Terminal?

Uh o. I have a sandbox app that uses security scoped bookmarks. Nobody's mentioned this to me so far. Just to throw some spaghetti at the wall, is it possible this could be related to not balancing -startAccessingSecurityScopedResource calls with -stopAccessingSecurityScopedResource when you are done with the file? If I remember from many years ago not doing this would eventually cause open/save panels etc. to no longer work in your app until after you reboot your Mac.