May seem like a dumb question but I'm somewhat overwhelmed by the amount of information and all the terms and conditions as it relates to this topic. There are several threads about cross platform issues, etc. as it relates to app groups but that is not my situation. Not too long ago I asked a similar question about a different app (not new but an update) and I just stuck with the group prefix on that one but I'd like to know what the recommendation is for a new Mac app. So I have this simple situation: I have a new Mac app. Two versions: Mac App Store (sandboxed) Non-Mac App Store (not sandboxed). They both use XPC service embedded in the app. XPC service + main app need an app group. Both non-MAS and MAS use app groups with their own XPC services (not with each other) I always used teamIdprefix.groupidentifier. So I configured and registered the group identifier for the outside the Mac App Store version because Xcode prompted me to. I'm using group. prefix (iOS style group). It seems to work fine. Is that the correct way for outside the Mac App Store? If I don't use group. prefix Xcode display the identifier in red like something is wrong. And for the Mac App Store version, is it now recommended to use iOS style groups from now on? Can the recommendation on this topic be simplified to always use the iOS style app group (group prefix not team id prefix) and only use team id prefix for historical reasons if you already have a deployed app using the old style? Or am I misunderstanding something? Thanks a lot.

Well Apple has pretty much dropped Objective-C and moved fully to Swift and SwiftUI becuase its faster and better to use. Worth learning it though. Interesting claims. When you say faster are you talking about performance or the speed in which you scratch your code? While it's obvious Apple is recommending Swift all the new AppKit API I'm aware of (or at least care about) for macOS 26.0 is available to Objective-C and I'm grateful or that. And how do you define better to use? Do you think the compiler gives better/more descriptive warning/error fixes in Swift than Objective-C? What about viewing variables in the debugger? What about compiler speed? I will continue to use Objective-C until I can't. My policy is currently this: -Any Swift only frameworks that are required (like Storekit2) must be wrapped inside its own framework or library. -All Swift code must be private API. All public API is Objective-C. -Main project remains Objective-C and continues on like Swift doesn't exist. Do I recommend this for new devs? No but that has more to do with Apple's public statements. It has nothing to do with Swift being "better" in any measurable way for me. I suspect one day that may change and I won't be able to use Objective-C anymore or I'll have to get an Objective-C runtime from GNUStep or something. Or maybe I'll just move to Electron or Flutter.

My apologies this actually isn’t actually causing a crash…the exception is being thrown but apparently caught.... I hit my exception breakpoint in the debugger last night and had assumed a crash was imminent (because typically you're not supposed to recover from this type of error)

Interestingly Preview.app seems to avoid the crash but they left the bug in for everyone else. cool.

Swizzle -_axPostPageChangeNotification: and don't call the original implementation avoids the crash... you're welcome

So I just spent quite a bit of time restructuring things in my app to use the new AppStore.requestReview(in:) My app is all Objective-C so I had to add a single Swift file just wrap the single class method in a @objc wrapped method. Why they can't just declare the AppStore.requestReview method @objc is beyond me. Then I had to sandwich an NSViewController in the mix. Before SKStoreReviewController +requestReview did not rely on the presence of a view controller (SKStoreReviewController always shows the request in a separate alert). But the new API has a NSViewController parameter that is not optional And guess what... after doing all that I discovered the new AppStore.requestReview(in:) does the exact same thing as the deprecated SKStoreReviewController +requestReview. The NSViewController parameter which is not optional is completely ignored and the review is presented in a separate alert just like SKStoreReviewController. It is not presented as a sheet. What a complete waste of time. Seriously who is designing these APIs....who deprecates something with another method that does the exact same thing as the old method....the only thing the new method does is require Swift.

FB20489224

Additionally, the up-down arrows are drawn even when the button isn’t hovered over. Hmm prior to Tahoe the arrows did draw even when the mouse wasn't hovered inside. Upgrading to Tahoe this does not happen. I just verified this change in behavior in a test project (using the code from my previous post): Add UIDesignRequiresCompatibility to Info.plist and set it to YES. Run the app. Arrows draw even while mouse is not hovering over it. Change UIDesignRequiresCompatibility entry back to NO and the arrows do not remain. So they changed stuff in macOS 26. Maybe there is a way you to get the pre Tahoe behavior if you play with some of the button properties. Someone from Apple should know. If there is no way to get this behavior for "free" on Tahoe you could always subclass. I don't think it should be too hard. . In the SwiftUI.Form style, the pop-up button shrinks its width to match the width of each option when the selection changes IMO I don't think a pop up button should adjust its width based on its selection b/c that can create a moving target for the user. I think it should take the width of its widest entry, or settle on a reasonable width and if there is an option with a long title let it truncate if that one option is selected. But what do I know I'm just a peasant developer :) You could resize on selection change if you want though.

@storj Cool story. For whatever reason I'm not getting email notifications when people respond to my threads. Still think it would be great if building with the 'Debug Configuration' caused the same permission error to accurately simulate the behavior you'll get in the wild but maybe there is a good reason why Apple doesn't want to do this. I dk.

Just to add: Continue drawing my section header background color in -drawRect: (windowBackgroundColor works for me) Oh right NSColor header file says not to use windowBackgroundColor for drawing so I'll pick something else. But avoiding the dynamic system colors in the collection view header view and adapting to light/dark mode manually does the trick.

so it looks like my NSView subclass which is my overrides draw rect. I wrote this like 7 or 8 years ago and forgot.. And in -drawRect I used NSColor +windowBackgroundGroundColor to fill the section header background. I must've added this because text in the section header was probably really blurry on non-retina displays. The NSTextField inside the section header is using the headerTextColor FWIW. So it appears Liquid Glass animation thing changes the top header text from black to white at certain points in the scroll. Not sure why, seems to be when section 0 scrolls on screen (even if we are not really even close to the top of it). Looks like maybe it's misinterpreting the background. Only a little bit of a collection view icon overlaps the section header (but the background is mostly white). The text should only turn white if it was overlapping a truly dark background. Not just like a partial overlap with a small icon in the collection view. Anyway if I remove my fill code in draw rect I see the Liquid Glass thingy draw a glass/shadow blur behind it so you can see the white text a bit. With windowBackgroundColor it was completely blending in. But even after removing my background fill...when the text turns white it still seems like a glitch. Sometimes the text doesn't reappear at all (when I scroll all the way to the top for instance and the header is completely behind white background, the text stays white) so I'd still like to disable. Is there good reliable override point for glass state so I can change the text color? I was unable to find any API in NSCollectionView header, NSSCrollView header to detect the scroll edge effect state?

Anyway so I can do the following to basically "disable it": Continue drawing my section header background color in -drawRect: (windowBackgroundColor works for me) Instead of using NSColor +headerTextColor: for the text In the header view use colors that aren't dynamic like: +NSColor.whiteColor for the text color in a dark NSAppearance +NSColor.blackColor for the text color in a light appearance. So either make a custom color in an Asset catalog for the above or just override -viewDidChangeEffectiveAppearance: and change the NSTextFields textColor directly based on the current appearance. I'm just drawing over the scroll edge effect rather than disabling it. But that'll have to do.

just watched the "Build an appkit app with the new design" video. There is a section on the scroll edge effect but there is no mention how to deal with it. How can I customize my drawing when my view is inside the "scroll edge effect" There was stuff about Split View, toolbar items, but nothing about collection view.

Nope I gave up on it.

FB20272917