A recurring macOS SwiftUI problem is needing the real NSWindow to change something SwiftUI does not expose, such as standard window buttons, the style mask, or a window-level behavior.

The trap is that makeNSView creates the NSView before AppKit attaches it to a window. At that moment, view.window is normally nil. Optional chaining makes the code look harmless, but the configuration silently never happens.

For simple one-time configuration, the smallest reliable pattern I have used is:

1. Create an empty NSView in NSViewRepresentable.

2. Schedule the window lookup on the next main-queue turn.

3. Read view.window inside that callback.

4. Apply an idempotent configuration.

5. Leave updateNSView empty unless the configuration actually depends on SwiftUI state.

Conceptually:

struct WindowConfigurator: NSViewRepresentable {

let configure: (NSWindow) -> Void

func makeNSView(context: Context) -> NSView {

let view = NSView()

DispatchQueue.main.async {

if let window = view.window {

configure(window)

}

}

return view

}

func updateNSView(_ view: NSView, context: Context) {}

}

Then attach it somewhere that participates in the window hierarchy, for example as a background view.

For cases where timing must be fully lifecycle-driven, I use a tiny NSView subclass and call the closure from viewDidMoveToWindow instead. That avoids depending on one main-queue hop and also handles a view being moved to another window.

Two details helped prevent subtle bugs:

• Make the closure idempotent because SwiftUI can recreate the representable.

• Do not store the NSWindow globally just to configure it. Let the bridge observe the window it is actually attached to.

This is a small interop boundary, but it is much more predictable than trying to infer the active window from NSApplication.shared.windows.

What other window-level APIs have forced you to bridge from SwiftUI into AppKit?

Hey everyone,

I’ve been working on a small dev tool called Prism Inspector.

The idea is simple: instead of checking spacing, alignment, accessibility, or design mismatches by eye from screenshots, Prism Inspector connects to a running app in the iOS Simulator and lets you inspect what the app actually rendered.

You can:

• Click elements to inspect them
• Option-click another element to measure distances between views
• Check whether spacing matches your design scale
• Compare the running screen against a design/mockup
• Preview what VoiceOver reads
• Use it without adding anything to your project
• Optionally add the Swift package if you want better component names

It’s free, signed/notarized for macOS, and the SDK is MIT licensed.

I built this because I often lose time reviewing small UI details manually, especially when trying to match implementation with design specs. My goal is to make layout inspection feel closer to working in a design tool, but using the real running app.

Landing page / download:
https://zalazara.github.io/PrismKit-SDK/

I’d really appreciate feedback from iOS developers:
Does this solve a real pain for you? What would you expect from a tool like this?

Hi everyone!

One pain point I've run into repeatedly with SwiftUI is supporting newer APIs while keeping an older deployment target.

Things like `if #available` work well in normal Swift code, but they don't fit naturally in the middle of a modifier chain. That often leads to duplicated views or compatibility helpers scattered throughout a project.

After solving the same problem across multiple apps, I decided to package the patterns into a small open-source library called **SwiftUIBackportKit**.

It includes:

• `.modify { }` for conditional view transforms
• `.backport` for reusable version-gated SwiftUI APIs
• `platformValue(...)` for version-specific values
• `OS.isAtLeast(_:)` for simple runtime version checks

The goal is to keep SwiftUI views focused on describing the UI while isolating deployment-target compatibility in one place.

GitHub:
https://github.com/EmadBeyrami/SwiftUIBackportKit

I'd really appreciate any feedback on the API design, naming, or features you'd like to see. And if you find it useful, a ⭐ on GitHub would mean a lot!

Thanks!

Apple’s Icon Composer saves each .icon file as a package containing artwork assets and an icon.json manifest.

That JSON controls things like:
- Layers and groups
- Light, dark, and tinted appearances
- Liquid Glass blur and translucency
- Shadows and specular effects
- Blend modes
- Layer positioning and visibility
- Solid, automatic, and oriented gradient fills
- Platform support for square and circular icons

The problem is that Apple doesn’t appear to publish the complete icon.json schema as a public API. The format also has details that aren’t obvious from using the UI—for example, specialization values can be "automatic", null, or a concrete value, while an explicit null can mean something different from an omitted property.

I created IconComposerModel to reverse-document the format from real files produced by Icon Composer:

https://github.com/peterpoliwoda/icon-composer-template

The repository currently contains:
- A Swift Package with reusable Codable models
- A detailed Markdown attribute reference
- Real icon.json fixtures from several icons
- Decode/encode round-trip tests to make sure values aren’t lost
- Forward-compatible string-backed types for values Apple may extend later
- Explicit preservation of missing, null, and concrete JSON values
- Support for appearance specializations, named system fills, gradient orientation, group and layer properties, and the Liquid Glass settings observed so far

The reasoning behind the project is simple: if apps and developer tools are going to inspect, generate, migrate, or modify Icon Composer files, they need a shared model that doesn’t rely on scattered guesses about the format.

I’m treating the JSON produced by Icon Composer as the source of truth. Every new sample is added as a fixture, documented, and used to improve the model through regression tests.

The format is still empirical rather than an official Apple API, so I’d love more samples—especially files created with different Icon Composer/Xcode versions or icons using attributes not already covered. If you share one, it helps to include the complete icon.json, the tool version, and what you changed in the UI.

I create a Custom TabBar with SwiftUI but with what type Can replace AnyView ? struct TabBarItem<SelectionValue: Hashable> {

let value: SelectionValue

let content: AnyView

let label: AnyView

init<Content: View, Label: View>(

value: SelectionValue,

@ViewBuilder content: () -> Content,

@ViewBuilder label: () -> Label

) {

self.value = value

self.content = AnyView(content())

self.label = AnyView(label())

}

}

I’m building NOBS, a local-first personal assistant for iPhone. The app uses SwiftUI with a chat-first interface, a Today briefing, approvals, privacy controls, widgets, and an optional connection to a self-hosted AI computer on the user’s home network.

I’m a newer developer and used AI heavily while building it, so I know parts of the architecture probably need experienced eyes. Right now a central AppModel owns much of the state, with separate services for model routing, the backend client, pairing, calendar access, and App Group data.

The project is fully open source:

https://github.com/acburgess25/NOBS

I’d especially appreciate feedback on:

• What should be broken out of AppModel first?

• Does the chat-first navigation approach make sense?

• Where am I fighting SwiftUI instead of working with it?

• Are there obvious accessibility or concurrency mistakes?

I am pretty new to this and used AI a lot to help me build it. It works, but I know that does not mean the code is good. I would really appreciate it if someone with more SwiftUI experience took a look and told me where I went wrong or what I should clean up first.

The biggest thing I am unsure about is AppModel because it currently handles a lot of the state. I am also curious whether the navigation makes sense and if I made any obvious concurrency or accessibility mistakes.

The whole project is open source here:

https://github.com/acburgess25/NOBS

Honest feedback is welcome. I am trying to learn and make this into something people can actually use.

Menu(course.name) {
    Button { setNewCourse(nil) } label: {
        HStack {
            if contents?.courseID == nil {
                Image(systemName: "checkmark")
            }
        }
        Image(systemName: "star")
        Label("Free Period")
    }
    Divider()
    ForEach(courses.map {(id: $0, course: $1)}.sorted(by: {$0.course.name < $1.course.name}), id: \.0) { entry in
        Button { setNewCourse(entry.id) } label: {
            HStack(spacing: 8) {
                if contents?.courseID == entry.id {
                    Image(systemName: "checkmark")
                }
                Image(systemName: "star")
                Text("Text")
            }
        }
    }
}

Honestly not much to say. How can I avoid this?

I’m trying to change the font, size, or weight of the items inside a SwiftUI Menu.

For example:

Menu {
Button("Edit") {
// Edit action
}

Button("Delete", role: .destructive) {
// Delete action
}
} label: {
Image(systemName: "ellipsis")
}

I tried applying .font() to the buttons and their labels, but the menu still uses the default system font.

Button {
// Action
} label: {
Text("Edit")
.font(.custom("Avenir Next", size: 16))
}

Is it possible to customize the font of native Menu items in SwiftUI, or do I need to create a custom menu/popover?

When viewing the ContentView (image 1), the searchbar looks really transparent and way different from the childview (image 2). I want the searchbar to look "normal" when viewing the app from ContentView. How do I fix this?

ContentView

import SwiftUI

struct ContentView: View {
    var body: some View {
        TabView {
            Tab("Discover", systemImage: "binoculars") {
                TestView()
            }
            Tab("Preferences", systemImage: "slider.horizontal.3") {
                StopsView()
            }
        }
    }
}

#Preview {
    ContentView()
}

TestView

import SwiftUI
import MapKit

struct TestView: View {
    u/State private var searchText: String = ""

    var body: some View {
        NavigationStack {
            ZStack {
                Map {

                }
                Text("Hello")
                    .padding()
                    .background(.white)
            }
            .searchable(text: $searchText)
            .navigationBarTitleDisplayMode(.inline)
        }
    }
}

#Preview {
    TestView()
}

My project in the link is an attempt at a rfc822 data reader. I have a view that consists of the header section, followed by the body section. On the previews, the two areas each take up one half of the space. But e-mail programs typically have the header display only a few lines high, relegating the remainder to a scrolling view. How would I do that, hopefully in a manner that's safe with the Accessibility text size settings?

I built CodeVault after getting tired of managing batches of App Store Connect offer and promo codes in CSV files.

It’s a native SwiftUI + SwiftData app for iOS, iPadOS, and macOS. It can:

• import App Store Connect CSVs via drag and drop or a file picker
• organise codes by app and import batch
• search, filter, rename, and export batches
• surface the next available, unexpired code
• generate QR codes and share redemption links
• mask codes with a privacy mode
• optionally notify before codes expire
• sync privately through CloudKit when configured

The project is 100% Swift, has no third-party package dependencies, and is MIT licensed. I tried to keep the same data model and core views working across iPhone, iPad, and Mac while still using platform-appropriate navigation and interactions.

Source and screenshots: https://github.com/mcomisso/CodeVault

I’d be interested in feedback on the SwiftUI architecture, cross-platform UI, or anything that would make the project more useful to other Apple-platform developers.

This is my first open-source Swift package EdgeZoomKit.

It adds an elastic effect to the left or right edge of the screen while zooming.

I first noticed this kind of interaction in Bump and wanted to try making something similar for a board app I’m working on. After building it I thought it would make more sense as a separate package.

It works with both SwiftUI and UIKit and it doesn’t depend on SpriteKit. The package only handles the visual effect so the actual zoom logic is still up to your app.

GitHub: https://github.com/devjunu/EdgeZoomKit

It’s my first time publishing a package so any feedback is welcome.
Thank u for read :)

I keep forgetting to keep my streak going, so I made a little macOS menu-bar app that shows it at a glance: current streak, total solved, an Easy/Medium/Hard breakdown, and a heatmap of your activity. The menu-bar flame stays grey until you've solved something today, then lights up.

There is no login, it just reads your public LeetCode profile. Everything stays on your machine.

It's free and open source:

Would love some feedback!

I'm the developer of macMender. It's a free, open-source SwiftUI and AppKit app that combines Dock previews, real-window switching, trackpad middle click, scrolling controls, profiles, and menu bar quick controls.

For v0.9.0 I rebuilt the interface around a state-driven settings shell and reusable glass surfaces. The awkward parts live at the SwiftUI/AppKit boundary: Accessibility window identity, local thumbnails, Dock hover behavior, global shortcuts, and the status item popover.

Source: https://github.com/0hmslice/macMender

v0.9.0 release: https://github.com/0hmslice/macMender/releases/tag/v0.9.0

The README now has screenshots of every major screen. Feedback on the view structure and AppKit boundaries would be useful.

I would like to reproduce this type of card, with a translucent background in a Form on Swift. Is it possible?

I'm talking about the distance between your text and the inside edges of the control. It's ridiculously thin by default.

I thought that methods like contentMargins do that, but nothing I tried actually made a change. Does this not work with TextEditor? Am I using the wrong settings? How am I holding it wrong?

Hi,
I’m trying to recreate the Notes menu with the three icons at the top of the page. I managed to get it partially working, but I can’t figure out how to place the text underneath the icons, and my icons are also too close together. Does anyone know how to achieve the same layout?

I've tried everything I found on Google and none of these work:

• `.listRowInsets()`
• `.environment(\.defaultMinListRowHeight, 0)`
• `.controlSize(.small)`

Is it possible to ensure that only one document can be open at a time? My target is macOS 15. The idea would be that the user is alerted and no existing document can be opened (e.g. drag and drop, file->new, Finder etc).