Post not yet marked as solved
Hi rksinghal,
The crash log you posted isn't complete (as it stops after the main thread), but one of the main reasons we see this sort of crash is when multiple threads are accessing the AppKit view hierarchy concurrently, which isn't supported. Can you double-check that you're not touching any views (including dirtying them for redisplay) on a background thread?
Hi eablokker,
On your NSToolbarDelegate, implement -toolbarSelectableItemIdentifiers: to return all of these item identifiers to give them the "you can click to select the whole toolbar item" behavior. Note also that to match the preference style, your items should have the bordered property set to false, since you won't need a separate button inside the item.
Post not yet marked as solved
Hi Hylas,
The main way you can learn about Dock geometry is via the -[NSScreen visibleFrame] property. That property returns a rect in screen coordinates which excludes the menu bar and Dock (along whichever edge it's configured) if visible. You can derive the inset created by the Dock by diffing this rectangle against the regular -frame property. Note that if there are multiple screens, the Dock will appear on only one of them.
Post not yet marked as solved
Hi tartiflette74,
That sounds like some very unusual drawing behavior! Off the top of my head, one possible way to get this behavior is via the view's layerContentsRedrawPolicy property. That property can be configured to prevent a view from redrawing when its frame size changes, but only if it's been customized away from its default value (NSViewLayerContentsRedrawDuringViewResize).
Otherwise, it would be most helpful to write up a report in Feedback Assistant with a small reproducing sample so that we can take a look. It's also helpful to know which version of macOS you're observing this behavior on. If you reply with a FB number from Feedback Assistant, I can help guide your report to the right place.
The macOS design system doesn't have the concept of an 'extra large' control size, so NSControl.ControlSize doesn't expose a case for it. SwiftUI controls automatically map .extraLarge to .large where necessary on macOS, so it's fine to use in multi-device views if you really want .extraLarge on another device.
Hi ski4funSonoma,
The dirtyRect behavior you're seeing is expected for a view with -[NSView clipsToBounds] set to NO, which is now the default for Sonoma-linked applications. The AppKit release notes touch on this, but here's a little more information.
The geometry of dirtyRect isn't too useful for determining where to draw your content. It's permissible for the dirtyRect to refer to any geometry that the view could draw but does not currently have fresh contents for. For unclipped views, that region is allowed to extend beyond the geometry of the view itself. Although this has always been part of -drawRect:'s API contract, it used to be very common to only see dirtyRect values that were equal to the bounds, so we've seen a number of cases where views accidentally rely on that specific behavior.
You should use the view's bounds as the basis for your path geometry. The dirtyRect is primarily useful for avoiding unnecessary work; for example, you could skip the cost of building a complicated Bézier path if you know it won't intersect the dirtyRect at all.
Post not yet marked as solved
At what point in the app's lifecycle are you calling -setActivationPolicy:?
Those windows are an implementation detail of menus. As a general rule, anything that appears on screen in our windowed environment is, itself, a window. That includes little bits of UI that you ordinarily wouldn’t think of, like typing suggestions, menu extras, context menus, and tooltips.
These can all appear in your application’s window list, alongside other framework-created panels like NSColorPanel and NSFontPanel, so use caution when acting on the array of all windows. If there’s a set of windows that you want to keep track of and iterate over, it’s often easier and more predictable to maintain your own list of those windows.
Hi sean.rich.dev,
Only a single sidebar at the leading edge of the window is allowed to span the full height and take space away from the titlebar.
However, if you're referring to the seamless full-height split dividers that you see in Mail and Notes, that's accomplished by putting a NSTrackingSeparatorToolbarItem in your toolbar. The separator item tracks a particular split divider to create distinct sections in the toolbar, and it also allows the split divider to extend up through the toolbar.
Post not yet marked as solved
If you're starting a new SwiftUI app that targets multiple platforms, it's strongly recommended to build a Mac target against the macOS SDK (which, as you noted, the Multiplatform app template sets up by default). This is the best way to build an idiomatic design for the Mac without any compromises.
SwiftUI on Mac Catalyst is a great option if you're already in the ideal spot for Mac Catalyst adoption (i.e. you have a lot of investment in an existing iPad application, and you'd like to bring it to the Mac) and you'd also like to incrementally adopt SwiftUI.
Post not yet marked as solved
Hi dwarfland,
Some possible answers to your questions, in order:
1) The one remaining piece that you might be missing is the "Full Size Content View" flag on the containing window. You have to allow content to underlap / scroll beneath the titlebar region to be eligible for a full-height sidebar.
2) This sounds like a good use case for NSTitlebarAccessoryViewController - https://developer.apple.com/documentation/appkit/nstitlebaraccessoryviewcontroller. You can install an accessory view controller on a window using the addTitlebarAccessoryViewController - https://developer.apple.com/documentation/appkit/nswindow/1419382-addtitlebaraccessoryviewcontroll method. A bottom bar accessory is automatically fit to the width of the content area (i.e. excluding the full-height sidebar) in Big Sur, and it fills the full width of the window on previous versions of macOS. And, as you remembered, accessories live inside the titlebar blur material, so there's no need to provide a separate background.
Thanks for the feedback about the documentation. While each of the individual pieces has a fairly complete class reference, I don't know of a guide or article that ties it all together, so I'll note that this is an area for potential improvement.
Post not yet marked as solved
Hi ps3zocker,
There isn't currently API in Mac Catalyst to customize the window's subtitle. I'd encourage you to write up a quick feedback requesting it in Feedback Assistant!
Hi andrewbuilder,
Although many of Xcode's app templates perform Core Data setup in the App Delegate, it's OK to set up your Core Data stack anywhere you'd like. So, if you want to adopt the new app/scene support in SwiftUI, one option is to set up a NSPersistentContainer in a custom class that you write, and then your SwiftUI App could hold on to an instance of that class in a variable. The SwiftUI Data Essentials - https://developer.apple.com/videos/play/wwdc2020/10040/ session might provide some inspiration on organizing your data and passing it through to your views.
On the other hand, if your app is still using a Storyboard and/or NSWindowController to host your SwiftUI content, you won't be able to set up the toolbar in SwiftUI, but you're free to configure the toolbar directly in AppKit. The 'Adopt the new look of macOS - https://developer.apple.com/videos/play/wwdc2020/10104/' session outlines some of the AppKit API that you'd use to customize your toolbar for the new design.
Post not yet marked as solved
Hi metalman,
Can you check a few things for me?
First, double-check that the window doesn't have "Hide Title Text" selected in the Interface Builder inspector. Second, if you remove the NSToolbar instance from your Interface Builder document and replace it with an in-code instantiation (setting the same delegate and applying it to the same window), does the problem go away?
If the all-code version works, that sounds like a framework bug that I would encourage you to file via Feedback Assistant.
As you discovered, NavigationView knows how to provide the full-height sidebar appearance for its first child view.
