I intentionally omit the part where I make excuses for defaulting on my ambition to post articles every 2 weeks, since I didn’t post anything for 4 months.

Oh wait…

What’s the point of this?

In a more complex SwiftUI Apps, as the Views get more heavy, the SwiftUI performance can quickly get out of hand. While the latest Apple devices are blazingly fast, we should still strive to not waste computation and power resources for unnecessary operations. And above all, I suppose pretty much everyone wants their App to run smoothly so that it feels just right. Let’s jump right into the next performance tip.

View Struct is your friend

The problem

After creating small View components I would write a bigger SwiftUI View that kinda is a UIViewController or NSViewController, and add name suffix - Screen. This Screen (heavily simplified) would usually look something like this:

@MainActor
final class LoginScreenModel: ObservableObject {

    @Published
    var username: String = ""

    @Published
    var password: String = ""
}

struct LoginScreen: View {

    @StateObject
    private var model: LoginScreenModel = .init()

    @State
    private var isAlertPresented: Bool = false // unused, just an example

    var body: some View {
        VStack {
            usernameField
            passwordField

            Spacer()

            loginButton
        }
        .padding()
        .toolbar { toolbarView }
    }
}

private extension LoginScreen {

    var toolbarView: some View {
        Button {

        } label: {
            Image(systemName: "xmark")
        }
    }

    var usernameField: some View {
        TextField("User name", text: $model.username)
            .padding()
            .background(.thinMaterial)
            .clipShape(RoundedRectangle(cornerRadius: 12))
    }

    var passwordField: some View {
        SecureField("Password", text: $model.password)
            .padding()
            .background(.thinMaterial)
            .clipShape(RoundedRectangle(cornerRadius: 12))
    }

    var loginButton: some View {
        Button("Login") {
            // Login logic
        }
        .buttonStyle(.borderedProminent)
    }
}

I always thought that once LoginScreenModel’s username property changes, it would trigger SwiftUI View diffing but only for the usernameField computed property, since it is the only place where model.username is used. But that’s not true, as I learned thanks to Instruments.

Whenever any StateObject’s or State property value changes, the whole var body: some View has to perform diffing and check for changes, but so do all computed properties and the computed properties’ subviews until it reaches another View struct that doesn’t depend on our LoginScreen’s State properties.

Keep in mind: Even though properties unrelated to the subview in question don’t trigger the actual redraw (on a CoreAnimation/CoreGraphics level), the SwiftUI diffing itself is pretty expensive, especially since it always runs on the MainActor.

We can verify this by adding this handy Self._printChanges() magic spice like so:

var usernameField: some View {
    let _ = Self._printChanges()
    
    ...
}

Now if you start typing into the password’s SecureField, thus changing the model.password, property on the LoginScreenModel, the console would output something like this:

LoginScreen: _model changed.

But of course in the case of an unrelated property, we don’t really need SwiftUI to even recompute the property to perform the diffing.

The Solution

What even Apple recommends is to break the Views not into computed properties, but separate structs. If we do decide to keep our usernameField computed property for var body: some View’s readability’s sake, we should create a separate struct like so:

fileprivate struct UsernameFieldView: View {

    @Binding
    var text: String

    var body: some View {
        let _ = Self._printChanges()

        TextField("User name", text: $text)
            .padding()
            .background(.thinMaterial)
            .clipShape(RoundedRectangle(cornerRadius: 12))
    }
}

and then refactor our computed property on the LoginScreen:

var usernameField: some View {
    UsernameFieldView(text: $model.username)
}

Now when you type into the password’s SecureField, the let _ = Self._printChanges() inside of the UsernameFieldView will not print anything. In our case this means that SwiftUI is not even recomputing the whole contents of UsernameFieldView since it knows that it only depends on the model.username and that hasn’t changed.

Conclusion

It’s embarassing, but after 3 years of working with SwiftUI this is something I learned just recently. As a good practice it’s probably to write it in a way that doesn’t do the unnecessary diffing straight away, but if your App’s performance is good enough and the Views are rather not complex, then there is no need to fall into the premature optimization trap 🪤. It’s all about striking the right balance.

Happy coding and stay tuned for more SwiftUI tips, (hopefully) coming up next week! 💻

What we want to achieve

If for some reason such as building a Color-configurable Theme Library or UI Library we can’t use the Xcode Asset Catalog, we will either need to create UIColor, NSColor and SwiftUI.Color with RGBA components, or, as often practiced, write an extension on UIColor, NSColor and SwiftUI.Color that allows us to initialize it from a Hex value.

However such a color doesn’t respect Light or Dark Mode and it can become a bit messy to always resolve two color versions in your View and read the UITraitCollection or ColorScheme environment.

But don’t worry, there is a simple solution to that, if we are willing to have some boilerplate!

The approach

In case you need to support both macOS and iOS, let’s start by defining Platform-agnostic typealiases for the UIColor and NSColor. While we can initialize a SwiftUI.Color directly and we don’t have to deal with UIColor and NSColor, we will need this to be able to dynamically resolve Dark and Light mode version of our colors as if they came from the Asset Catalog.

import SwiftUI

#if canImport(AppKit)
    import AppKit

    typealias PlatformColor = NSColor
#elseif canImport(UIKit)
    import UIKit

    typealias PlatformColor = UIColor
#endif

This will make sure that our dynamic color resolution works with both AppKit and UIKit.

Next, we need to add an extension on our new PlatformColor, so that we can initialize it from a Hex value

extension PlatformColor {

    /// Initializes the PlatformColor with Hex String
    /// - RGB (12-bit), ex. "FFF" for pure white
    /// - RGB (24-bit), ex. "FFFFFF" for pure white
    ///
    /// - Parameters:
    ///   - hex: Hex description of the color without the alpha channel
    ///   - alpha: Alpha/opacity to apply to the color, `by default 1.0`. The values have to be between 0.0 and 1.0
    convenience init(hex: String, alpha: Double = 1.0) {
        let hex = hex.trimmingCharacters(in: CharacterSet.alphanumerics.inverted)
        var int: UInt64 = 0
        Scanner(string: hex).scanHexInt64(&int)

        let r, g, b: UInt64
        switch hex.count {
        case 3: // RGB (12-bit)
            (r, g, b) = ((int >> 8) * 17, (int >> 4 & 0xF) * 17, (int & 0xF) * 17)
        case 6: // RGB (24-bit)
            (r, g, b) = (int >> 16, int >> 8 & 0xFF, int & 0xFF)
        default:
            (r, g, b) = (0, 0, 0)
        }

        self.init(
            displayP3Red: Double(r) / 255,
            green: Double(g) / 255,
            blue:  Double(b) / 255,
            alpha: alpha
        )
    }
}

Note that the Hex color has to be a String in either RGB or RRGGBB format.

As of now, we can initialize UIColor and NSColor with a String Hex color value like so:

let myColor = PlatformColor(hex: "#FFFFF")

And to be able to create a SwiftUI.Color with just one initializer and not two, since the one taking NSColor and the one taking UIColor are different, a new initializer will do the trick:

extension Color {

    init(platformColor: PlatformColor) {
        #if canImport(AppKit)
        self = Color(platformColor)
        #else
        self = Color(uiColor: platformColor)
        #endif
    }
}

Now finally to the fun part!

Dynamically resolve Color based on Dark or Light mode

As mentioned above, to save us some headache we will bridge through the PlatformColor by extending it with a static method:

extension PlatformColor {

    static func dynamicColor(light: PlatformColor, dark: PlatformColor) -> PlatformColor {
        #if canImport(AppKit)
        return PlatformColor(name: nil) { $0.isDarkMode ? dark : light }
        #else
        return PlatformColor { $0.userInterfaceStyle == .dark ? dark : light }
        #endif
    }
}

For the UIKit version of PlatformColor we are initializing it with the init(dynamicProvider:) and for the AppKit version of PlatformColor we are using the init(name:dynamicProvider:) initializer. Since the AppKit version contains NSAppearance that has many different appearances, I have also created a convenience computed property that returns true if we have Dark Mode enabled on macOS:

#if canImport(AppKit)
extension NSAppearance {

    var isDarkMode: Bool {
        switch name {
        case .aqua, .vibrantLight, .accessibilityHighContrastVibrantLight, .accessibilityHighContrastAqua:
            return false
        case .darkAqua, .vibrantDark, .accessibilityHighContrastVibrantDark, .accessibilityHighContrastDarkAqua:
            return true
        default:
            return false
        }
    }
}
#endif

Now when we create a PlatformColor with our dynamicColor method, it will become one instance of PlatformColor that will apply the Light or Dark mode version based on the system traits, so we should end up with something like this:

let myPlatformColor = PlatformColor.dynamicColor(
    light: .init(hex: "#FFF"),
    dark: .init(hex: "#000")
)

let myColor = Color(myPlatformColor)

Final steps

And since us programmers are lazy (or at least I am 😳), I want to have an even more convenient way of creating the color with SwiftUI on all platforms. To do so, I added one more initializer (as if it’s not enough already) that will make it more convenient than ever before!

extension Color {

    /// Initializes the Color with Light and Dark Hex String
    /// - RGB (12-bit), ex. "FFF" for pure white
    /// - RGB (24-bit), ex. "FFFFFF" for pure white
    ///
    /// - Parameters:
    ///   - lightHex: Light Mode Hex description of the color
    ///   - darkHex: Dark Mode Hex description of the color, if nil, Light Mode Hex is used
    ///   - opacity: Alpha to apply to the color, `by default 1.0`. The values have to be between 0.0 and 1.0
    init(lightHex: String, darkHex: String, alpha: Double = 1.0) {
        self = Color(
            PlatformColor.dynamicColor(
                light: PlatformColor(hex: lightHex, alpha: alpha),
                dark: PlatformColor(hex: darkHex, alpha: alpha)
            )
        )
    }
}

And now we can store our Colors as easily as this:

enum MyAppColors {

    static let contentPrimary: Color = Color(lightHex: "#000000", darkHex: "#FFFFFF")
}

or in UIKit/AppKit case:

enum MyAppPlatformColors {

    static let contentPrimary: PlatformColor = PlatformColor.dynamicColor(
        light: .init(hex: "#FFF"),
        dark: .init(hex: "#000")
    )
}

Conclusion

With this approach we can replace the Asset Catalog’s colors with programatic Hex values! This enables to have better control over our Colors and better searchability. Also this can come in handy in case you are building some UI SDK that needs to have configurable Theme of colors that support both light and dark mode, which can get a bit tricky with relying only on Asset Catalog.

I wish Xcode also could preview the color as a rectangle next to the Hex value (please,  Apple 🙏), but I guess for now we have to use VSCode 🤡.

As always, I will be happy for any feedback!

Happy coding! 💻

Coming Next 🔜

As of writing this article (Sep 15) I honestly don’t know yet 😅 but don’t worry, I will figure something out 🤞!

What we want to achieve

A window that would float on top of all other windows and can be triggered on any macOS space by pressing a user-customizable hotkey window, just like Spotlight.

My approach

Let’s start by defining some simple View such as this HotkeyView that mimics the Spotlight search bar, but of course that can be any View of your liking.

struct HotkeyView: View {

    @State
    private var text: String = ""

    // Since we have a TextField here, we want to make it focused on appear
    @FocusState
    private var focused

    var body: some View {
        HStack(spacing: 16) {
            Image(systemName: "magnifyingglass")
                .resizable()
                .frame(width: 24, height: 24)

            TextField("My hotkey window", text: $text)
                .font(.title)
                .textFieldStyle(.plain)
                .focused($focused)
        }
        .padding()
        .foregroundStyle(.primary)
        // Setting a static width will save us some headache when centering the NSPanel
        .frame(width: 750)
        .onAppear {
            focused = true
        }
    }
}

Hotkey Recording

While we can create our own implementation, I really recommend using a library called KeyboardShortcuts. It’s reliable, very easy to use, and can get you started in minutes.

Let’s add it to our project by going to Xcode > File > Add Package Dependencies… and pasting the KeyboardShortcuts GitHub URL in the search bar.

First, for convenience’s sake, we define an extension on the library’s KeyboardShortcut.Name like so 👇 . It is not only a good practice, but also it will prevent us from misspelling the name later on or in case it is renamed in the future.

extension KeyboardShortcuts.Name {
    static let openHotkeyWindow = Self("openHotkeyWindow")
}

Now we need to create some Settings Scene where we would let the user customize the hotkey. Of course, the setting doesn’t need to be inside native Settings Scene, however, that’s usually where the user would logically look for hotkey settings. The use of the native Settings allows the App Settings to be opened by pressing ⌘+. What’s most important is the use of KeyboardShortcuts.Recorder(for: .openHotkeyWindow) to have a SwiftUI View that allows us to record the hotkey with our custom name.

struct SettingsScreen: View {

    var body: some View {
        HStack {
            Text("Configure Hotkey")

            KeyboardShortcuts.Recorder(for: .openHotkeyWindow)
        }
        .padding()
    }
}

And then inside the var body: some Scene in our @main App struct we need to add this:

Settings {
    SettingsScreen()
}

Hotkey Handling

Since we have our convenient KeyboardShortcuts library, listening to our hotkey being pressed is as simple as this:

KeyboardShortcuts.onKeyUp(for: .openHotkeyWindow) {}

If you run your app and put some debugPrint or a breakpoint inside this closure, you should see it being called.

Now that we are listening to our hotkey presses and we have our HotkeyView in place, we can move on to making it appear when the hotkey is pressed.

Issues along the way 😢

I have attempted to use a WindowGroup(id:) and WindowGroup(value:), and then opening such window with @Environment(\.openWindow) in the hotkey handling closure, but unfortunately as of macOS Sequoia it still doesn’t have the desired effect, and UtilityWindow did not help either. For me the window wasn’t opening on the current space I was at with Mission Control, sometimes the window didn’t float on top of everything else and I had issues with having it appear in fullscreen mode.

Resorting to AppKit

Initially, I tried experimenting with NSWindow that would take in a SwiftUI View in the parameter, but then I have stumbled upon this article Make a floating panel in SwiftUI for macOS that suggested using NSPanel. When comparing the behavior with Spotlight, it seems like NSPanel is the way to go. It works well with multiple spaces and screens and it by default is dismissable by pressing the esc key. Taking from the article, I have slightly modified the proposed NSPanel subclass like so:

final class FloatingPanel<Content: View>: NSPanel {

    init(
        view: () -> Content,
        // We need to provide NSRect since the NSWindow doesn't inherit the size from the content
        // by default. Not setting the contentRect would result in incorrect positioning
        // when centering the window
        contentRect: NSRect,
        didClose: @escaping () -> Void
    ) {
        self.didClose = didClose

        super.init(
            contentRect: .zero,
            styleMask: [
                .borderless,
                .nonactivatingPanel,
                .titled,
                .fullSizeContentView
            ],
            backing: .buffered,
            defer: false
        )

        /// Allow the panel to be on top of other windows
        isFloatingPanel = true
        level = .statusBar

        /// Allow the pannel to be overlaid in a fullscreen space
        collectionBehavior = [.canJoinAllSpaces, .fullScreenAuxiliary, .transient, .ignoresCycle]

        /// Don't show a window title, even if it's set
        titleVisibility = .hidden
        titlebarAppearsTransparent = true

        /// Since there is no title bar make the window moveable by dragging on the background
        isMovableByWindowBackground = true

        /// Hide when unfocused
        hidesOnDeactivate = true

        /// Hide all traffic light buttons
        standardWindowButton(.closeButton)?.isHidden = true
        standardWindowButton(.miniaturizeButton)?.isHidden = true
        standardWindowButton(.zoomButton)?.isHidden = true

        /// Sets animations accordingly
        animationBehavior = .utilityWindow

        /// Set the content view.
        /// The safe area is ignored because the title bar still interferes with the geometry
        contentView = NSHostingView(
            rootView: view()
        )
    }

    private let didClose: () -> Void

    /// Close automatically when out of focus, e.g. outside click
    override func resignKey() {
        super.resignKey()
        close()
    }

    /// Close and toggle presentation, so that it matches the current state of the panel
    override func close() {
        super.close()
        didClose()
    }

    /// `canBecomeKey` is required so that text inputs inside the panel can receive focus
    override var canBecomeKey: Bool {
        return true
    }

    // For our use case, we don't want the window to become main and thus steal the focus from
    // the previously opened app completely
    override var canBecomeMain: Bool {
        return false
    }
}

In the original implementation there was an issue that the instance was never deallocated after closing the NSPanel, because there wasn’t any callback that would signal that the window was closed. For that I added didClose closure.

I have also modified it so that it doesn’t have to be tied to an existing View with a ViewModifier by a Binding.

Last steps

To encapsulate logic in one place, I have created a class FloatingPanelHandler that holds a reference to an instance of our NSPanel and in case our hotkey is pressed again, it would dismiss the NSPanel if already open, just like Spotlight.

final class FloatingPanelHandler {

    private var panel: NSPanel?

    init() {
        KeyboardShortcuts.onKeyUp(for: .openHotkeyWindow) {
            // We don't need [weak self] here since this class will be alive during the whole
            // lifecycle of the App.
            if self.panel == nil {
                let panel = FloatingPanel(
                    view: {
                        // Create the SwiftUI View that you want to be shown
                        // in the floating window
                        HotkeyView()
                    },
                    // If you want your window to be perfectly centered, we need to provide
                    // proper width and height. For our case, since the height is pretty small,
                    // it's ok-ish to just pass 0 as the height (Designers, please don't kill me)
                    contentRect: NSRect(x: 0, y: 0, width: 750, height: 0),
                    didClose: {
                        // When `didClose` gets called, make sure to remove the reference
                        // to allow it to deallocate
                        self.panel = nil
                    }
                )

                // It's important to activate the NSApplication so that our window
                // shows on top and takes the focus.
                NSApplication.shared.activate()
                panel.makeKeyAndOrderFront(nil)
                panel.orderFrontRegardless()
                panel.center()

                self.panel = panel
            } else {
                // If the panel is already shown and the hotkey is pressed again,
                // we close it and nullify the reference
                self.panel?.close()
                self.panel = nil
            }
        }
    }
}

As a last step we need to save an instance of the FloatingPanelHandler in our @main App struct, simply by adding:

private let floatingPanelHandler = FloatingPanelHandler()

Since reading the Hotkey is closure based, this is sufficient to make your App always listen to the keyboard shortcut the user has defined and open the hotkey window.

The result 🎉

Voila! Now we should be able to open the SwiftUI View on any space, regardless of full-screen mode, it should automatically take focus, and close when pressing esc or when clicking outside of the window. As of macOS Sequoia there still seems to be an issue with SafeArea insets when a SwiftUI view is wrapped inside a NSHostingView 👀 To make sure that the SafeArea gets ignored properly for our SwiftUI View, check out my previous article How to hide toolbar in macOS App’s window in SwiftUI!

We can then change our FloatingPanel subclass’s init at the bottom as follows:

contentView = NSHostingViewSuppressingSafeArea(
    rootView: view()
)

This should give us the desired result 🚀

Conclusion

While this approach has a lot of room for improvement, it’s the only thing that I got working with multiple spaces and monitors support after spending many hours on it (cries in building SwiftUI apps on macOS 🥲)

Happy coding! 💻

Coming Next 🔜

In the next article we will take a look at how to ~create a ScrollView with custom Pull actions~ programatically resolve dynamic UIColor/NSColor from Hex values in Light and Dark Mode!

Edit

When working on my app today (20th Sep 24) I found out that the code has been creating a strong reference to the SwiftUI View. I have modified the code so that strong reference cycle no longer happens 🙏

The problem 🤔

For my Todo list app “Simply Things” that I am currently building I wanted to have a Spotlight-like hotkey window that I could trigger with a keyboard shortcut anywhere to add a new Thing to do that looks like this: Starting with macOS 15.0 (WWDC24: Tailor macOS windows with SwiftUI) we can easily hide the toolbar for macOS windows:

.toolbarVisibility(.hidden, for: .windowToolbar)

But what I got as a result was this: So I thought I would just need to apply .ignoresSafeArea() and my problem would be solved, but that only pushed the content behind the now invisible toolbar background, leaving a padding on the bottom that I couldn’t get rid of:

The solution 💡

It’s not a perfect one, but we need to go back to AppKit. No matter what I have tried in SwiftUI, it doesn’t seem like there is a sensible way to ignore the window toolbar’s safe area completely. In order to work around this, first I have created a subclass of NSHostingView that ignores the Safe Area. Unfortunately without doing this adding even a negative padding to the view would not successfuly make the content go underneath the title bar without creating a space at the bottom.

final class NSHostingViewIgnoringSafeArea<T: View>: NSHostingView<T> {
    required init(rootView: T) {
        super.init(rootView: rootView)

        addLayoutGuide(layoutGuide)

        // Pinning the view to the edges
        NSLayoutConstraint.activate([
            leadingAnchor.constraint(equalTo: layoutGuide.leadingAnchor),
            topAnchor.constraint(equalTo: layoutGuide.topAnchor),
            trailingAnchor.constraint(equalTo: layoutGuide.trailingAnchor),
            bottomAnchor.constraint(equalTo: layoutGuide.bottomAnchor)
        ])
    }

    override func viewDidMoveToWindow() {
        // We need to set the alpha value to 0 here, since
        // before the title bar computation is done, the view might jump.
        // We will be setting the alpha back to 1 after computation is finished.
        window?.alphaValue = 0
        super.viewDidMoveToWindow()
    }

    private lazy var layoutGuide: NSLayoutGuide = NSLayoutGuide()

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override var safeAreaRect: NSRect { frame }

    override var safeAreaInsets: NSEdgeInsets {
        NSEdgeInsets(top: 0, left: 0, bottom: 0, right: 0)
    }

    override var safeAreaLayoutGuide: NSLayoutGuide { layoutGuide }

    override var additionalSafeAreaInsets: NSEdgeInsets {
        get { NSEdgeInsets(top: 0, left: 0, bottom: 0, right: 0) }

        set {}
    }
}

Once we have this in place, we need to be able to calculate the title bar’s height. Coming from iOS we might want to just get the Key Window of the NSApplication, compute the title bar height and apply negative padding, but with macOS we might not have a NSWindow at all for our app while trying to compute the height, so it’s not very reliable. For reliability we should create a NSViewRepresentable that will grab its NSWindow and calculate the title bar height. Let’s also not forget to set the alpha back to 1 for the window.

struct WindowHiddenToolbarView<Content: View>: NSViewRepresentable {

    init(
        contentTopPadding: Binding<CGFloat>,
        content: @escaping () -> Content
    ) {
        _contentTopPadding = contentTopPadding
        self.content = content
    }

    @Binding private var contentTopPadding: CGFloat
    private let content: () -> Content

    func makeNSView(context: Context) -> NSView {
        let view = NSHostingViewIgnoringSafeArea(
            rootView: content()
        )

        DispatchQueue.main.async {
            if let window = view.window {
                let windowFrameHeight = window.frame.height
                let contentLayoutFrameHeight = window.contentLayoutRect.height
                let titlebarHeight = windowFrameHeight - contentLayoutFrameHeight
                contentTopPadding = -titlebarHeight

                // We need to make sure to set alpha back to 1, since we are setting
                // it to 0 in NSHostingViewSuppressingSafeArea
                window.alphaValue = 1
            }
        }

        return view
    }

    func updateNSView(_ nsView: NSViewType, context: Context) {}
}

Using our newly created WindowHiddenToolbarView will do the job already, but we would need to keep a @State in our view and apply the negative padding, but here comes a ViewModifier to our rescue 🎉!

struct WindowHiddenToolbarModifier: ViewModifier {

    @State
    private var contentTopPadding: CGFloat = 0

    func body(content: Content) -> some View {
        WindowHiddenToolbarView(
            contentTopPadding: $contentTopPadding,
            content: { content }
        )
        .toolbarVisibility(.hidden, for: .windowToolbar)
        .padding(.top, contentTopPadding)
    }
}

extension View {

    func windowToolbarHidden() -> some View {
        modifier(WindowHiddenToolbarModifier())
    }
}

This neat modifier allows us to be able to hide the toolbar just like that

TheView()
    .windowToolbarHidden()

And voila! We have a SwiftUI view that hides the toolbar and completely ignores the Safe Area!

Targeting older macOS Versions

If you need to target older macOS versions and cannot use the .toolbarVisibility(.hidden, for: .windowToolbar) modifier, inside of WindowHiddenToolbarView you can change the makeNSView method like so:

    func makeNSView(context: Context) -> NSView {
        let view = NSHostingViewIgnoringSafeArea(
            rootView: content()
        )

        DispatchQueue.main.async {
            if let window = view.window {
                let windowFrameHeight = window.frame.height
                let contentLayoutFrameHeight = window.contentLayoutRect.height
                let titlebarHeight = windowFrameHeight - contentLayoutFrameHeight
                contentTopPadding = -titlebarHeight

                // This makes sure we hide the title bar as well as the buttons
                window.titlebarAppearsTransparent = true
                window.titleVisibility = .hidden
                window.styleMask.insert(.borderless)
                window.styleMask.remove(.closable)
                window.styleMask.remove(.fullScreen)
                window.styleMask.remove(.miniaturizable)

                // We need to make sure to set alpha back to 1, since we are setting
                // it to 0 in NSHostingViewSuppressingSafeArea
                window.alphaValue = 1
            }
        }

        return view
    }

Final Thoughts 🔚

While this solution is far from perfect, this seems like the only sensible way to achieve this but perhaps I am missing something 🧐. I will be very glad for any suggestions on how to achieve the same result, since I would be happy to remove this boilerplate in my own project myself 😅!

Coming Next 🔜

In next article we will take a look at how to create a Spotlight-like hotkey window, stay tuned!

For quite some time now I have been thinking about starting my own blog about Swift development but I have never felt confident enough. However, over the past 5 years of developing in Swift, even though I admittedly sometimes do smart things like dividng by zero and expecting my app to work 🤡, I have realized that I do have valuable things to share, and that’s exactly why I am starting this blog!

My intention is to write articles somewhat periodically, ideally at least twice a month 🤞.

If you have any suggestions/comments regarding:

• 🌱 how to make the blog better to provide better learning value
• 🐛 a bug in code
• ⚠️ mistakes in text

or just want to chat about 👨‍💻 coding, ✈️ travelling, 🎻 music or anything else really, feel free to hit me up! (Links are down below in the footer)

In a perfect world scenario this blog would serve as a handy learning source for beginners and advanced  iOS, macOS, watchOS and visionOS developers!

Big thanks to my friend and a 🌟 stellar Swift developer Daniel Saidi for planting a seed in my head that I could start my own blog, and to my friends for supporting me that I actually should do it.

Let’s learn together 🚀 !

_{The blog name feels cringy, but definitely better than something like Daniel’s Swift Oddysey 😄}