macOS
Toolbar customization is a staple of a true Mac app with any amount of complex functionality. I want toolbar customization, you want toolbar customization, your users want toolbar customization. However, setting it up using SwiftUI can be less than obvious – or, at least, much less so than when using NSToolbar.
AppKit
The AppKit Debug menu is a debugging tool that has been shipping as part of the framework and hence macOS itself for a few years. The Dump Menu debug feature is a new addition in macOS 27 that I think could be useful.
SwiftUI
In my previous post, In-Process Animations and Transitions with CADisplayLink, Done Right, I outlined some of the use cases for implementing custom animations, as well as how to use CADisplayLink to help you drive the animations you create. CADisplayLink tells us when to perform updates. However, in that post we
Apps
With the introduction of the Swift-native AttributedString in iOS 15 and macOS 12, it’s become pretty common to convert between the existing NSAttributedString and the new type. Certain first-party frameworks, like SwiftUI and App Intents, require developers to use the new AttributedString. In existing apps, simply moving off of
SwiftUI
I have already written about another gnarly bug around document-based apps in SwiftUI in a previous post. In that post, I found that on visionOS, any DocumentGroup scene would duplicate your view hierarchy, causing pretty funny looking visual overlaying glitches. It was most visible on visionOS due to the amount
SwiftUI
Custom modifiers in SwiftUI are a great way to reuse code. However, that should never lead to obfuscating semantics. And, unfortunately, most use cases for conditional modifiers do both of those things. Here's why.
SwiftUI
When it comes to writing good user interface code, and code in general, it’s not exactly groundbreaking to claim that in any given situation, we should strive to use the right tool for the right job. When working with tools and frameworks that are designed to seem simple on
Apps
SwiftUI undoubtedly has a lot of impressive capabilities and features, but unfortunately transparency is not one of them. Many components are designed and built as black boxes, with developers left attempting to piece together the full picture using the sparse information gathered from the documentation, WWDC videos, and reverse engineering.
macOS 14 and iOS 17 saw the introduction of the Observation framework and the Observable macro, allowing your SwiftUI views to automatically update in response to underlying data changing. However, that initial implementation contained really limited capabilities for consuming Observable types from outside SwiftUI. Before macOS 26 and iOS 26
Admittedly, in-process animation and transition techniques on macOS are not as widely applied or evolved as they may be on iOS and iOS-derived platforms, and information and advice around them can be scattered and oftentimes outdated. So, let’s fix that and try to outline some best practices, as well
SwiftUI
TL;DR: As a result of a gnarly regression, every document-based SwiftUI app on visionOS 2.4 is duplicating views, rendering document-based app completely unusable on the platform. I was working on porting one of my side project apps from macOS to visionOS, and at some point wanted to test
AppKit
While working on a behavior that required dynamically switching between the nonactivating panel behavior and one that is more similar to the regular window behavior, I discovered a subtle but significant issue in AppKit: changing the NSWindowStyleMaskNonactivatingPanel flag after an NSPanel has been initialized doesn't fully update the
