FB15195096

FB15209556

Okay so after going through the Xcode release notes I found this bit: "The Project Navigator now defaults to creating groups with associated folders when using the “New Group” and “New Group from Selection” commands. To create a group without a folder, hold option in the context menu to reveal the “New Group without Folder” variant of the command. (127396845)" New Group is nowhere to be found at all when there is a selection underneath an expanded blue folder in the navigator though (even if you right click on the background). You have to move the selection up to the top level to get "New Group" to show up in the context menu (and then I can hold down option key to get "New Group without Folder"). So in the case of a brand new project you have to move the selection up to the top (where you would go to edit build settings) then right click the background to get "New Group (without folder)" THEN I can create a "Supporting Files" group without a folder. However this all appears to be very buggy. After moving the .entitlements to the new group (with no folder) it still actually moves the file to the root directory next to the.xcodeproject file. In a brand new Xcode project the top level folder that contains all the starting files like the App Delegate is blue (not gray). Files cannot be reordered via drag and drop. When I right click on any file like AppDelegate.m there is no "New Group from Selection" option. There is only "New Folder from Selection". I thus cannot create a "New Group without Folder" or reorder any of the files in a starter Xcode project without actually moving the files....

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. Why does a new Xcode project create a folder reference in the project navigator now by default instead of a group? This must be considered a bug?

Thank you for replying. I was having a hard time reproducing the issue in a sample project. Upon further inspection I discovered that simply using a custom shape window without a title bar is not sufficient to reproduce the issue (and may not be related to it at all). Specifying: Application is agent (UIElement) to YES in Project Settings -> Info is also required (so no dock icon) triggers this behavior. The documentation (in the archive which I believe has not been superseded) states: LSUIElement (Boolean - macOS) specifies whether the app runs as an agent app. If this key is set to YES, Launch Services runs the app as an agent app. Agent apps do not appear in the Dock or in the Force Quit window. Although they typically run as background apps, they can come to the foreground to present a user interface if desired. A click on a window belonging to an agent app brings that app forward to handle events. When the application is agent (which mine is) and the window is on a screen NOT equal to mainScreen the menu bar doesn't move over with the click. BUT if the window has a title bar (which mine doesn't because it can't, as I need the custom shape) the menu bar does travel with the click but only if you click on the title bar (if you click anywhere else on the window the screen doesn't become mainScreen).

I filed FB15237355 Is there a workaround you could recommend? I tried overriding -sendEvent: in my window subclass and passing the events to the application but none of that has made the screen active. I imagine I should be able to reroute the event when I receive it when self.screen != NSScreen.mainScreen to a code path that would trigger the screen I'm on to become the main screen

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.

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?

@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?

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.

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

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).

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.

FB15493942

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}