Hi, I'm Phil Zakharchenko. This is my personal blog with thoughts and ideas around application development on Apple platforms, macOS user interface, Swift, AppKit, SwiftUI, and technology in general.
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
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.
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
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
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
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.
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
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
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
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
At this point, AppKit developers with their finger on the pulse may be familiar with setting subtitles on NSMenuItem using the subtitle property, which has been available since macOS 14.4. In fact, I was the one who added it back when I worked at Apple. Achieving the same in
This project demonstrates a collection of techniques for consolidating various Mini vMac variations into one application, enabling better code reuse and simplifying maintenance.
Swift 6 language mode promises compile-time stricter concurrency checking, aimed at preventing and eliminating data races, runtime memory corruption, as well as other common but hard to debug issues. While adopting the new language mode can be a bit of a challenge for larger or less modular projects, Swift 6