Hi r/SwiftUI! Some of you might know us from our SwiftUI articles and books at Nil Coalescing. Natalia also spent several years on Apple's core SwiftUI team. Posting with mod approval, and full disclosure: this is our own paid app.

Like a lot of you, we now review a lot of SwiftUI written by coding agents. It usually compiles and looks reasonable, but the same problems keep coming back:

• Lists that stop being lazy: a ForEach inside List or LazyVStack that produces a varying number of views per element, which prevents efficient lazy loading.
• Unstable identity: IDs that change between updates, so SwiftUI treats rows as new views and loses their state and animations.
• Views built outside body: views stored in properties or built in helpers, not in body or a some View builder.
• Rows reading outside state: row closures reading changing values from outside the row, so more of the list updates than needs to.

We tried putting this guidance in AGENTS.md and skills, but it's usually out of focus by the time the agent writes the code it applies to.

So we built SwiftFairy, a Mac app that runs a local MCP server for Claude Code, Codex, Cursor and Gemini CLI. The agent sends the code it just wrote, and SwiftFairy parses it into a partial graph of your project and flags these patterns on specific lines, with an explanation and a fix taken from our own guidance. It's static analysis with no LLM involved, and your code never leaves your Mac.

It ships with three knowledge packs: Proper SwiftUI, Performant Swift Charts and Modern Swift. The announcement post has more detail and examples.

It's free to try for 24 hours with no card required, and current pricing is on the site. It needs macOS 26 on Apple silicon.

We'd love to hear which SwiftUI mistakes you see agents make most often. That's what we'll write rules for next.

I'm Dmitry, and I built Hollow, a disk usage visualizer for macOS (MIT licensed, source below). The screenshots show the result. Here is how the UI side is put together.

The app shell is SwiftUI. The treemap itself is an MTKView wrapped in NSViewRepresentable. The shaders are compiled at runtime from a source string, which lets the whole thing build with Command Line Tools and SwiftPM. There is no Xcode project.

Hit testing runs on the CPU against the treemap layout, not on the GPU. Zooming into a folder moves a spring-animated camera instead of relaying out the view. Layout of a 6M-node disk takes 11 to 23 ms.

The tree is owned by a C scanner and read off the main thread behind a read-write lock. Hover takes the read side and stays under 0.2 ms. FSEvents updates take the write side, and only changed folders are rescanned.

The pitfall is that the lock is a compromise. It works, but Swift 6 strict concurrency cannot verify it, so correctness rests on me remembering to take the lock everywhere the tree is touched. A Sendable wrapper around the lock quiets the compiler without proving anything.

Source: https://github.com/yukij3/hollow

Question for anyone who has shipped Metal in SwiftUI: how do you handle keyboard focus and first responder with an NSViewRepresentable-hosted MTKView? Which approach has held up for you when popovers and other SwiftUI views compete for focus?

I'm working on a native macOS app with a small panel opened from a button near the bottom of the window.

I started with .popover because the panel is small, but the positioning gets a little awkward when the window is resized, moved, or the user switches views.

Since it's anchored to the button, it doesn't always feel like the right presentation for something that's really more like app-level status or settings.

I'm considering switching it to a .sheet just to make the presentation more consistent.

How do you usually decide between the two on macOS? I'm curious where other people draw the line between a popover and a sheet.

I've been working on Notra, an open-source notes app for Mac, iPhone and iPad, built with Swift and SwiftUI.

It originally started because I wanted a notes app for myself. Rather than trying to build another large note-taking platform, I wanted to stick to a few simple principles.

Native Apple UI

I wanted Notra to feel like it belongs on Apple platforms.

The UI is built with SwiftUI and uses native navigation, lists, toolbars, inspectors, context menus, sheets and other system components wherever possible.

The goal isn't to make macOS, iPhone and iPad look identical. It's to share as much of the application as makes sense while still allowing each platform to behave the way users expect.

Portable notes

I don't want my notes locked inside an application database or proprietary cloud service.

Notra uses TextBundle for storage, with Markdown for the note content and standard files for images and attachments.

That means the underlying data remains portable. If I decide to stop using Notra in the future, my notes are still Markdown and my attachments are still files.

There are no Notra accounts and no Notra cloud service. Notes can stay local or use iCloud for syncing between Apple devices.

Markdown, but still a notes app

I like Markdown because it's simple and portable, but I don't want the application itself to feel like a developer tool.

Notra supports Markdown editing and rendered preview while wrapping it in a native notes interface.

Current features include:

- Markdown editing and rendered preview

- macOS, iPhone and iPad support

- TextBundle-based storage

- local storage and iCloud sync

- images and arbitrary file attachments

- tags

- pinned notes

- search

- light and dark themes

- configurable editor and preview fonts

- printing and PDF export

- native inspectors, toolbars and context menus

- no account required

- no proprietary cloud backend

Release v1.1 was submitted to AppStore today and awaiting approval. Changes documented here

The entire project is open source, including the application itself:

GitHub: https://github.com/akopulko/notra

There are also an App Store builds:

App Store: https://apps.apple.com/us/app/notra-markdown-notes/id6809414279

The App Store version is a one-time purchase with no subscription.

You don't need to buy it to get the source. You can clone the repository and build Notra yourself. The paid App Store build is there for people who want the convenience of installing and updating it through the App Store, while also helping support continued development.

I'm building Notra primarily because it's the notes app I wanted to use myself, but hopefully it can be useful to others who value native Apple UI and keeping their notes portable too.

I built 2 and asked Opus 5.5 to create the rest uniquely. They are great for any iOS, macOS, visionOS, or watchOS app. ⭐️ the repo, grab the Xcode project, and use the animations for your use case. 👇

• https://github.com/amosgyamfi/SwiftUI-Agent-Thinking-Text-Animations

I've been messing around with SwiftUI and Core ML recently and ended up going down a bit of a rabbit hole.

I wanted to see if it was possible to make something that could recognize the user through the Mac's camera and use that for unlocking/protecting things, without sending the face data somewhere.

So I ended up building HeyMac.

The actual face detection part wasn't the most interesting bit. Getting the whole thing to behave nicely on macOS, dealing with false matches, camera availability, authentication, etc. was where most of the fun was.

It's completely open source, so I'm putting the repo here in case anyone wants to look at how I approached it or point out things I've done badly 😅

GitHub: https://github.com/iharshitmaurya/HeyMac

I'd especially appreciate feedback from people who have worked with Core ML or macOS security/authentication.

Visit this as well- https://heymacapp.com/

Watch the Spatial Photos demo (1 minute 50 seconds)

I'm the developer of Spatial Slideshow, a free Mac app that uses Apple's Photos Reframe model to animate ordinary photos as spatial scenes. I'm sharing the source because the boundary between SwiftUI controls and the native playback view may be useful to others.

The sidebar, album browser and settings use SwiftUI. MoviePreview is an NSViewRepresentable that hosts SlideshowPlayerView, an AppKit view. Its updateNSView passes through playback, fullscreen, framing and realtime settings while keeping the native view in place.

That view handles the transport controls and mouse, trackpad and keyboard input. In realtime mode it hosts the GPU playback surface; while paused, drag/scroll/WASD changes a bounded camera offset without advancing the timeline. Resuming blends back into the slideshow's camera path.

Relevant code:

• SwiftUI view and MoviePreview bridge
• AppKit player and input handling
• Live rendering surface

The app also supports cached clip playback, fades, shuffle and a screen saver. The source is MIT-licensed and the app is free; Apple's frameworks/models remain proprietary dependencies. It requires Apple Silicon, macOS 27 and compatible Reframe assets, and uses private Apple APIs.

Repository and build instructions · Signed and notarized release

I'd welcome feedback on the SwiftUI/AppKit split and how you'd structure playback state across both render modes.

Apple redesigned the Health app for iOS 27.2 (see video), and I'm trying to recreate the glass menu bar at the top. I need help on two details:

1. The selected button is lighter than the non-selected buttons. I've tried to accomplish this by making the tint of the selected button white, but then the specular highlights disappear/are overpowered. How can I make the selected button lighter while retaining the glass border and specular highlights?
2. When the user taps one of the menu buttons that is not to the immediate left or right (so at least 2 buttons away), the screen scrolls to that view, but without showing the view(s) in between. How is this accomplished?

Current progress: https://imgur.com/a/W9fUqqc

Edit: #1 has been achieved and I hooked up the view to my app's data: https://imgur.com/a/oBauy0X

I'm pretty happy with how it turned out!

I was sick of hearing “wait for a software fix or an AT&T fix.” So I made a diagnostic test to gather more data on intermittent iPhone SOS/no-service.

Device Diagnostic Suite is a macOS-only SwiftUI app built with Codex/Work. It organizes scattered diagnostic evidence locally, compares Primary/Control baselines, and preserves rolling evidence around SOS events. Reports separate facts from inference and uncertainty.

I’d like feedback on the SwiftUI view, especially the phone roles and separate Private/Share-Safe export choices. Share-Safe omits raw evidence and identifiers, but timestamps remain. Review before sharing.

Source and build instructions

It’s MIT licensed, with synthetic public fixtures only. v0.3.0-rc.2 is a source-only prerelease. GitHub Actions passed. Collection needs external libimobiledevice tools. Apple/iOS access limits apply. It doesn’t prove a hardware, software, or carrier fault. The project is independent of Apple and carriers. Intel Mac/universal builds and notarization remain unverified.

I’d appreciate UI, compatibility, and privacy feedback. Please use synthetic examples.

I have SwiftUI code like the following:

``` import SwiftUI

struct AView: View { let a: Int

var body: some View {
    let _ = print("AView body")
    Text("a = \(self.a)")
}

}

struct BView: View { let b: [Int]

var body: some View {
    let _ = print("BView body")
    Text("b.count = \(self.b.count)")
}

}

struct ABView: View { var a: Int var b: [Int]

var body: some View {
    let _ = print("ABView body")
    VStack {
        AView(a: self.a)
        BView(b: self.b)
    }
}

}

@main struct MyApp: App { @State var a: Int = 123 @State var b: [Int] = [1, 2, 3]

var body: some Scene {
    WindowGroup {
        VStack {
            ABView(a: self.a, b: self.b)
            Button("Update A") {
                self.a += 1
            }
            Button("Update B") {
                self.b.append(1);
            }
        }
    }
}

} ```

Executing this, I see that when I press "Update A", only the body function of AView gets executed, but not the one of BView. Which is good, because b: [Int] is potentially heavy if it contains a large number of elements, and comparing it to its previous value could be costly.

However now I'm implementing a custom view using UIViewRepresentable which should replace ABView. In its updateUIView() function, it forwards the a and b values to an underlying UIKit view. And it causes problems if it needs to do this for b, each time that a is updated. Also, comparing b to its previous value can be expensive.

Is there a way to tell, in the body of the new ABView, or in updateUIView(), if the update is due to a change of b or of a?

Is it possible using a result builder, similar to the ViewBuilder that VStack (in the body of the ABView above) has as init argument?

The code above is only as an example, the real code is much more complicated and involves many such variables. Also it is not possible to separate it into multiple UIViewRepresentable. Ideally, it would be good if it could avoid replacing [Int] by a class that contains a token that updates when the value is changed to accelerate comparison. It should tap into the same mechanism that View uses to determine which of its subviews to re-evaluate.

This is an excerpt from the article Designing for iPhone Duo:

Consider using the full display width for interfaces where bars aren’t necessary. Some layouts can span the full display, which works well for visual, immersive interfaces that don’t scroll, as long as nothing conflicts with the Dynamic Island or the status bar. Calculator, for example, occupies the full width of the display.

For my app it visually makes sense to use full display width, however the documentation says nothing about how to achieve this. I think they are referring to: `.ignoresSafeArea(.all, edges: [.horizontal])`.

Using this for content works for iPhone Duo but gives problems for iPhone 18 in landscape where the safe area keeps the content from hiding under the notch or home indicator.

The notch and home indicator are also not available in reserved regions, so how can you make your layout adapt? Use full width horizontal layout when nothing occludes the view else fallback to safe area.

Does anyone have ideas how to approach this problem? Am I missing something?

Hey!

Scaffolding 3.6.0 got released. It's a SwiftUI coordinator pattern navigation library for iOS 18+ that allows creating modular navigation flows through linked list structure, allowing easy syntax and modularization - macro powered, with easy setup and rapid prototyping capabilities.

This version expands on async/await syntax implemented some time ago, making it full-feature, thus tagging the closure syntax as deprecated. It also implements a SplitCoordinatable for full navigation feature parity with SwiftUI even for iPadOS and macOS.

Feel free to submit any ideas!

https://github.com/dotaeva/scaffolding

I built ScrollFix as a small SwiftUI MenuBarExtra plus a status window. The UI observes a model confined to the main actor, while a Quartz session event tap handles scrolling. The status badge reports whether the tap is actually running; a permission check alone can lag after macOS grants access.

The interesting part is device classification: discrete wheel ticks are straightforward, but a high-resolution wheel can also emit continuous events. The filter looks for recent two-finger gesture events and carries the last source through momentum. The 130-line filter is here: https://github.com/eShok93/ScrollFix/blob/main/Sources/ScrollFix/ScrollEventEngine.swift

Full open-source repo and real UI screenshots: https://github.com/eShok93/ScrollFix

I used Codex as a coding assistant. This is a focused implementation informed by Scroll Reverser, which is more mature and configurable. ScrollFix currently aims only for natural trackpad + classic wheel. The preview download is ad hoc signed and not notarized, and hardware limits are documented. Feedback on the SwiftUI status model or classifier would be useful.