I have a question about the app lifecycle when my app is launched via a Shortcut. I'm adding a INIntent to a Mac app. So my app delegate implements: - (nullable id)application:(NSApplication *)application handlerForIntent:(INIntent *)intent Then my custom intent handler implements the two protocol methods -confirmIntentNameHere:completion: and -handleIntentNameHere:completion: During my testing -applicationDidFinishLaunching: is called before the intent methods, so I can forward methods to my main window controller to perform the shortcut actions, since it's already ready. ....But if this is not always the case, I can still perform them but I'd have to move the code out of the window controller to perform the action "headless" if invoked before my app has built its UI. Just wondering if this is something I should be prepared for. Thanks in advance.

If I do this: NSString *name = @"Jim"; NSMenuItem *menuItem = [[NSMenuItem alloc]init]; // Analyze does show localization warning when format string is used. menuItem.title = [NSString stringWithFormat:@"Hello %@",name]; I expect to get the following warning: User-facing text should use localized string macro But I don't. However if I do this: menuItem.title = @"What"; I do get the warning about localization as expected and as desired when I run Analyze. Is this considered a bug? Thanks!

My framework has private Objective-C API that is only used within the framework. It should not be exposed in the public interface (so it shouldn't be imported in the umbrella header). To expose this API to Swift that's within the framework only the documentation seems to indicate that this needs to be imported in the umbrella header? Import Code Within a Framework Target To use the Objective-C declarations in files in the same framework target as your Swift code, configure an umbrella header as follows: 1.Under Build Settings, in Packaging, make sure the Defines Module setting for the framework target is set to Yes. 2.In the umbrella header, import every Objective-C header you want to expose to Swift. Swift sees every header you expose publicly in your umbrella header. The contents of the Objective-C files in that framework are automatically available from any Swift file within that framework target, with no import statements. Use classes and other declarations from your Objective-C code with the same Swift syntax you use for system classes. I would imagine that there must be a way to do this?

I have an NSWindow that isn't entirely opaque. When presenting a sheet AppKit overlays the window with NSSheetEffectDimmingView. The problem is the entire window frame is used so NSSheetEffectDimmingView overlays the transparent areas of the window and it looks bad. Is there a clean way to inset NSSheetEffectDimmingView or even perhaps disable this behavior completely so I can draw my own? I'm looking for a clean solution (other than modifying the view hierarchy of NSNextStepFrame) or swizzles which I might have to resort to if there is no other way.

If I try making a bitmap of a NSButton using the following code: NSBitmapImageRep *rep = [button bitmapImageRepForCachingDisplayInRect:button.bounds]; [button cacheDisplayInRect:button.bounds toBitmapImageRep:rep]; NSData *tiffData = rep.TIFFRepresentation; I get a blank image if the NSButton has its bezelStyle set to NSBezelStyleGlass. If I change the bezel style to something else like NSBezelStyleFlexiblePush I do get an image

I'm noticing some weird glitches with my collection view headers on macOS Tahoe. The sections headers are pinned to the visible region. I headers fade out when scrolling and are supposed to fade back in but sometimes they don't fade back in and the header remains but the header text doesn't come back (until I scroll again). How can I turn off this scroll animation thingy?

I have some buttons. I set the bezelStyle to NSBezelStyleGlass. I'm sometimes experiencing the following issue: Put the system in dark mode. Some glass buttons still draw with the light appearance. One or more of the following actions usually makes the appearance redraw proper: -Clicking the button -Deactivating and then reactivating the window. -Close and then reopen the window. I tried setNeedsDisplay YES etc. but that didn't work The delay is quite noticeable. Everything else is in dark mode except one or two glass buttons. This seems to workaround the issue: BOOL didToggleGlass = NO; if (self.bezelStyle == NSBezelStyleGlass) { // Turn glass off just for a sec. self.bezelStyle = NSBezelStyleToolbar; didToggleGlass = YES; } if (didToggleGlass) { // Put glass back on. self.bezelStyle = NSBezelStyleGlass; } Apparently toggling glass cause the effective appearance to change so you can't use the above workaround in a -viewDidChangeEffectiveAppearance b/c you'll create an infinite loop unless you guard against it.

I have an NSBrowser inside a window. When I start resizing a column I noticed a peculiar behavior: it causes NSWindowWillStartLiveResizeNotification to get posted for the NSWindow the browser is inside (and did end gets posted when column resizing finishes). The browser is not the NSWindow contentView but a descendant of the contentView. I have my reasons for caring (I'm currently listening for these window resize notifications) but my code naively assumes that NSWindowWillStartLiveResizeNotification - NSWindowDidEndLiveResizeNotification indicates a window resizing session, not a column resizing session for the NSBrowser. This is in contrast to NSOutlineView. When resizing columns in NSOutlineView the window resize notifications do not get posted. NSBrowser deliberately kicks it off: -[NSWindow _startLiveResize]; -[NSBrowser _resizeColumn:withEvent:] () So this seems quite intentional but is it necessary in modern macOS? Should I file a bug? I already did FB20298148

Looking to update one of my apps that uses SKStoreReviewController +requestReview (deprecated) to AppStore.requestReview(in:) umm...I have a few of questions... Why is an NSViewController parameter required? It's really not so uncommon for an AppKit app to just use NSWindowController with a window that does not use NSViewController... It should be possible to present the review request in a standalone alert (attached to a window is preferred IMO but it still should be possible to ask in separate window). 3)...why Swift..(err nevermind) Ideally: AppStore requestReview should take a NSWindow parameter but that parameter should be optional. If nil the request should be presented in a standalone window (like an alert). If non nil..present as a sheet on the window. Why a view controller? Maybe I'm missing something.

Getting this crash after I do this in PDFKit a lot: PDFSelection *nextSelect = [self.pdfView.document findString:currentSearchString fromSelection:currentSelction withOptions:NSCaseInsensitiveSearch]; if (nextSelect != nil) { self.pdfView.currentSelection = nextSelect; [self.pdfView scrollSelectionToVisible:nil]; } Which often leads to: 0 CoreFoundation 0x000000019ced4770 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000019c9b2418 objc_exception_throw + 88 2 CoreFoundation 0x000000019cfffe10 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 724 3 CoreFoundation 0x000000019cfa1ae4 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 52 4 PDFKit 0x00000001cb56e0fc -[PDFView _axPostPageChangeNotification:] + 348 5 Foundation 0x000000019e6a25e4 __NSFireDelayedPerform + 372 6 CoreFoundation 0x000000019ce92290 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 7 CoreFoundation 0x000000019ce91f50 __CFRunLoopDoTimer +

I have a custom object which gets passed back to the main app from XPC. I whitelist it like so: NSSet *expectedClass = [NSSet setWithObjects:[NSArray class], [MyCustomClass class], nil]; [interface setClasses:expectedClass forSelector:@selector(myMethodNameHere:withCompletion:) argumentIndex:0 ofReply:YES]; Now my custom class conforms to NSSecureCoding. It does have an array property of another custom class. @property (nonatomic,readonly) NSArray *arraypropertyOfOtherClass; Which is decoded in -initWithCoder: using: -decodeArrayOfObjectsOfClasses:forKey: Now on macOS Tahoe this is all walking fine. But I just tested on macOS Monterey and I get the following error: Exception: decodeObjectForKey: too many nested collections when explicitly decoding a single collection. How should I handle this for earlier versions of macOS?

I just updated to macOS 26.1. I have a pure AppKit app (I guess that's not possible anymore but as close to a pure AppKit app as you can get). I use NSButton with the glass bezel style and SF symbol images. It looks like the minor OS update brought layout changes because now some of these buttons are scaling the symbol image much larger than was being done on macOS 26. The image can sometimes draw outside the glass 'bezel'. It looks like using the 'info' symbol in a button results in much larger image scaling than it did on the previous Tahoe for some SF Symbols. With the glass bezel style and a SF Symbol image how am I supposed to consistently make the button look good? With certain symbols I have to use imageScaling NSImageScaleProportionallyUpOrDown and on others I have to use NSImageScaleProportionallyDown. If I'm using a system image shouldn't it just do the right thing? Is trial and error the only way to tell? That's what I was doing before but it seems that the minor 26.1 update changed things. Additionally calling -sizeToFit on a button multiple times can cause it to shrink for example: [button sizeToFit]; // <-- At fitting size // Then later [button sizeToFit]; // Now button is shrunk But if the button is already at its fitting size an additional call later shouldn't make it shrink, it should stay the same size. FB20517174 I see I now inherit SwiftUI, not sure if that has anything to do with this but if I wanted to opt in to fragile layout I wouldn't be using Appkit...

Appkit starting logging these warnings in macOS 26.1 about my app's MainMenu. **Internal inconsistency in menus - menu <NSMenu: 0xb91b2ff80> Title: AppName Supermenu: 0xb91a50b40 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: () believes it has [<NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp:] 0xb91a50b40> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu ** I don't what that means. The supermenu is the menu that represents the menu used for my app's menu bar (as described by NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp Everything seems to work fine but log looks scary. Please don't throw!

Returning to a Mac Catalyst app that I put to the side for awhile..when running it on Xcode 26.1 it crashes at launch with: Assertion failure in -[NSToolbarItemGroupView _layoutWrapperViewsWithAttributes:], NSToolbarItemGroupView.m:599 No attributes were found for item Call stack has a bunch of Autolayout code in AppKit like: [NSWindow(NSConstraintBasedLayoutInternal) _layoutViewTree] + 120 50 AppKit 0x00000001911e8a10 -[NSWindow(NSConstraintBasedLayoutInternal) layoutIfNeeded] + 240 51 UIKitMacHelper 0x00000001a98f293c -[UINSWindow layoutIfNeeded] + 56 A few unnamed symbols mixed in maybe that's that Swiftness beneath the surface. App is just murdered on launch. I assume this is related to using NSToolbarItemGroup when building an NSToolbar... I do see this log out: NSToolbarItemGroup does not support selectionMode. Create the group with one of the class constructors to support selection. Which is an interesting log so I commented out all calls to setSelectionMode: but still the same crash. I do set the groups subitems property directly (I do not use the class constructors as the logging statement above indicates). I have no idea if using the class constructors will workaround this issue or not but I'm not particularly excited about that idea because I have items in the same toolbar group with different actions.

When I run my Mac Catalyst app I'm getting unacceptable performance when resizing the window. Window resizing is very unresponsive/laggy. Configuration: The root view controller is a UISplitViewController (three pane split using UISplitViewControllerStyleTripleColumn). Sidebar is configured. It's using a UICollectionView sidebar style (so it looks like NSOutlineView in AppKit). On initial launch there is no selection and the second and third view controllers in the split have empty placeholder view controllers. At this point window resizing is fine. Now I make a selection in the sidebar. This populates the supplementary view controller with a view controller that uses a UITableView. Now resizing the window performance is awful. Basically this is unusable. When resizing the window a bunch what looks to be Core Animation related logs flood the console during window resize: cannot add handler to 3 from 1 - dropping Library: QuartzCore | Subsystem: com.apple.coreanimation Now if I go to my app's Info.plist and add: UIDesignRequiresCompatibility entry with a value of TRUE and follow the same steps described above window resizing works as expected and I do not experience performance issues. Also with UIDesignRequiresCompatibility there is no "cannot add handlers" error logs flooding the console on window resize.