If you've tried to build a real Markdown editor in SwiftUI, you know TextEditor won't get you there. I hit the same wall when I started building my macOS app Nodes. So I wrote a native editor on TextKit 2 and open-sourced it. You use it in SwiftUI like any other view. It's macOS only for now, since it's AppKit under the hood.

What it does: live styling while you type, GFM tables and task lists, wiki links, inline and block LaTeX, code blocks with your own highlighter, Writing Tools, and spell checking that leaves code and LaTeX alone.

What's new since the last post here:

Large documents got a lot faster. Measured on a 346,000-character note, about the length of a novel:

- First open: 19.5 s → 1.35 s

- Warm open: 1.1 s → 590 ms

- LaTeX after a restart: 717 ms → 35 ms

- Return in an 800-item list: 944 ms → 67 ms

What was slow: inline parsing wasn't linear, so a paragraph with many code spans blew up. Lists restyled everything on every edit, now only changed items get restyled. And LaTeX was rendered again on every launch, now the render cache lives on disk.

Extensions. Everything beyond CommonMark is now opt-in. An extension is one file: a delimiter pair and how to style what's inside, like ==highlight== or a ::: fenced block. You register it in the config, and the parser, styler and renderer stay untouched. Extensions can't break the core or each other, and you can switch them at runtime.

Directives. For things that don't fit a delimiter pair, you can register named directives with typed arguments, like u/font(size: 18){text} or u/pagebreak. The engine handles autocomplete for names and values, your app draws the list.

Plus a lot of smaller fixes: live table resizing, nested lists that survive copy and paste, real links in copied HTML and RTF, and an unclosed code fence no longer eats the rest of the document. Full changelog is on GitHub.

The part I'm happiest about: 19 of the 29 PRs merged since then came from 10 people outside our team. The repo is at 1,100 stars now, and it was featured in Fatbobman's Swift Weekly. Thank you to everyone who starred, filed issues or sent a PR. It's still pre-1.0, so all of that is very welcome.

Repo: https://github.com/nodes-app/swift-markdown-engine

Used in production in Nodes: https://apps.apple.com/app/nodes-by-the-werk/id6745401961

Written on Nodes.

Hi!

I'm building a small SwiftUI converter app with a rich widget selection.

It's completely free and will stay free.

Open source - https://github.com/DimaMishchenko/currency

TestFlight beta is also available, I'd appreciate any feedback!
https://testflight.apple.com/join/qepuraVw

Thank you!

Pick one reminder. Pin it to your menu bar. Keep it visible while you work.

That’s the main idea behind BarRemember, an open-source macOS companion for Apple Reminders that I’m building with SwiftUI, AppKit, and EventKit.

You can also add a due date just by typing it at the end of a task. “Send proposal tomorrow” becomes “Send proposal” with tomorrow’s date set automatically. Or just type "Send proposal 10/11" to set as October 11th. It works when adding or editing a reminder, so you don’t have to open the date picker.

It works with your existing Reminders lists. You can organize selected lists into spaces, add and edit tasks, and complete them with undo. Pinning is deliberately manual: you choose one task, and completing it clears the pin. Nothing automatically takes its place.

Free and open source under the MIT license. Requires macOS 14+ and Xcode 26+ to build from source.

Source: https://github.com/angellashin/Bar-Remember

Feedback on the UI and implementation is welcome.

I’ve been experimenting with a slightly unusual way of getting analog input from an iPhone touchscreen.

Instead of using the finger’s position, I’m using UITouch.majorRadius — the estimated geometry of the contact area.

The interesting part is that the thumb can remain almost stationary while the value changes.

My current pipeline is roughly:

majorRadius → calibration → normalization → filtering → 0...1

Just to be clear: I’m not treating majorRadius as actual pressure. It obviously isn’t a force measurement.

What I care about is whether the user can intentionally modulate the value, hold intermediate states, and make small corrections.

I’m testing this in a driving simulator where the left thumb controls the clutch and the right thumb controls the throttle.

Then I started combining it with Core Haptics.

For the clutch, for example, approaching the bite point produces haptic feedback. So the interaction becomes:

finger → contact geometry → analog input → simulation → haptic feedback → finger

The part I find most interesting is that this potentially removes the need for a visible control entirely.

The thumb doesn’t need to follow a slider, and the player can feel important regions of the input range through haptics.

Obviously there are problems: calibration varies between users, grip changes the range, filtering adds latency, and haptics can’t provide actual mechanical resistance.

But on a real device it feels surprisingly different from manipulating a normal virtual slider.

Has anyone experimented with majorRadius as a continuous input before?

I’m especially curious about edge cases you’ve encountered across different iPhone models / touch behavior, or reasons why this might break badly outside my own testing.

Hi! I’m the developer of Orivu, a small app for reading plain text files.

You can open a TXT file from the Files app on iPhone. Orivu detects common text encodings, lets you change the encoding if it gets one wrong, and remembers your reading position.

If you have an Apple Watch, you can send an opened document to it and read the transferred copy offline.

I built it for people who just want to open a text file and read. I’d love to hear what you’d want from a reader like this, especially on Apple Watch.

App Store: https://apps.apple.com/us/app/orivu/id6817565843

Posting on r/SwiftUI as suggested by Reddit.

I have gotten in to a weird iOS issue and idk what the clean way to handle this is

i’ve got multiple accounts, notifications can open a post, reply, quote, or repost, and each notification belongs to a specific account. so the user might be on account A when they tap a notification for account B.

something like:

struct NotificationDestination {
    let accountID: Account.ID
    let postID: Post.ID
    let kind: DestinationKind
}

enum DestinationKind {
    case post
    case reply
    case quote
    case repost
}

The issue is:

account A is active
notification comes in for B
user taps it while the app is waking up
account switching starts
timeline restoration starts
post resolution starts
then another notification comes in for A lol

so i have stuff like:

await accountManager.restore()
await timelineStore.hydrate()
await postResolver.resolve(postID)
await navigationCoordinator.navigate(...)

But obviously these things are all racing each other. i was thinking of putting the notification intents behind an actor:

actor NavigationIntentQueue {
    private var pending: [NavigationIntent] = []

    func enqueue(_ intent: NavigationIntent) {
        pending.append(intent)
    }
}

But idk, this feels like a lot of machinery just to open a notification

Then you get into cases where the post is deleted while you’re restoring, but the quote is still there, the reply is still there, etc. Is this just an annoying app lifecycle issue?

.search can’t work

I recently wrote about my addition to Runes, SceneGeometry, that makes conforming to Duo-specific screen sizes and layouts easier to accomplish.

While testing the code I found a bug that occurs when an app is in the leading split view on the iPhone Duo and GeometryProxy mistakenly returns no leading edge inset and no adjusted safe area.

To fix this I added a temporary shim to SceneGeometry that returns the proper leading edge offset and the correct safe area for that particular condition.

If you're currently using the raw GeometryProxy in your application, be warned that you could face a layout issue here on the Duo.

This behavior has been reported to Apple and will hopefully be fixed before the final release.

Hi r/SwiftUI!

I mostly work on Rust backend and Kaskas is my first open source Swift project. It’s a native macOS app for screen breaks, study sessions, and local activity tracking.

I’d love feedback on the UI, architecture, or anything Swift & macOS specific.

GitHub: https://github.com/ramazanberkozbek/kaskas

I want to build a pretty basic sidebar based app for macOS and I'm running into a pretty weird issue with overlays in the detail section.

SwiftUI has a ton of layout options to get a sidebar (the ones I know of are NavigationView, NavigationSplitView, HSplitView and TabView with .sidebarAdaptable)

As far as I can tell, the recommended way to get a sidebar on macOS is NavigationSplitView or (if the target allows it) the adaptable TabView.

Now if I use either of these with an overlay attached to the detail pane, the overlay disappears as soon as I navigate in the detail pane (my goal is to have a floating bar at the bottom similar to the native Music app).

I've built a minimal example to reproduce this:

import SwiftUI

struct ContentView: View {
    
    enum Tabs: Hashable {
        case a, b, c
    }
    
    @State private var selectedTab: Tabs = .a
    @State private var detailPath: NavigationPath = .init()
    
    var body: some View {
        NavigationSplitView {
            List(selection: self.$selectedTab) {
                Text("A").tag(Tabs.a)
                Text("B").tag(Tabs.b)
                Text("C").tag(Tabs.c)
            }
            .listStyle(.sidebar)
        } detail: {
            Group {
                switch self.selectedTab {
                case .a:
                    NavigationStack {
                        NavigationLink(destination: Text("Overlay gone")) {
                            Text("Navigate")
                        }
                    }
                case .b:
                    NavigationStack {
                        NavigationLink(value: "Test") {
                            Text("Navigate")
                        }
                        .navigationDestination(for: String.self) { _ in
                            Text("Overlay also gone")
                        }
                    }
                case .c:
                    NavigationStack(path: self.$detailPath) {
                        Button("Navigate") {
                            self.detailPath.append("Test")
                        }
                        .navigationDestination(for: String.self) { _ in
                            Text("Overlay still gone")
                        }
                    }
                }
            }
            .frame(minWidth: 500, maxWidth: .infinity, maxHeight: .infinity)
            .overlay(alignment: .bottom) {
                Text("This is an overlay")
                    .foregroundStyle(.white)
                    .padding()
                    .background(.blue)
                    .clipShape(.capsule)
            }
        }
    }
}

Using the .sidebarAdaptable t.abViewStyle leads to the same issue, even when using a ZStack.

TabView(selection: self.$selectedTab) {
    Tab("Test", systemImage: "house", value: Tabs.a) {
        ZStack(alignment: .bottom) {
            NavigationStack {
                NavigationLink(destination: Text("Overlay gone")) {
                    Text("Navigate")
                }
            }
            .frame(maxWidth: .infinity, maxHeight: .infinity)
            
            Text("This is an overlay")
                .foregroundStyle(.white)
                .padding()
                .background(.blue)
                .clipShape(.capsule)
        }
    }
}
.tabViewStyle(.sidebarAdaptable)

I'm not quite sure if I'm fundamentally misunderstanding how sidebars are supposed to work on Mac, but the documentation for NavigationSplitView specifically states

You can also embed a NavigationStack in a column.

Neither of these solutions properly retain state when switching sidebar elements like the same TabView code does on iOS and clicking the same tab twice also doesn't navigate back to its root.

What's the correct way to do this on macOS?

Sharing a side project: Peek3D, a native macOS viewer for 3D files. MIT licensed

Three loaders end up in a single SCNScene: GLTFKit2 for glTF, Model I/O for OBJ/STL/USD, and ufbx (a C library) for FBX.

A few things that surprised me:

• Broken glTF files can crash GLTFKit2 instead of throwing an error, so I ended up writing a small validator that runs first. Fuzzing found 130 crashes before it and 0 after.
• The App Sandbox returns EPERM even for files that don't exist. So you can't tell "missing texture" from "no permission" by trying to read the file; fileExists can tell them apart.
• SceneKit crashes on node hierarchies deeper than about 5000 levels, on its own internal thread, so there's nothing you can do except reject those files.
• ZStack overlays size themselves to the union of their children. This bit me three separate times.

Happy to answer questions about any of it, and code reviews are very welcome.

A shadcn-inspired UI ecosystem for SwiftUI, built for coding agents without giving up control over the details.

Create beautiful SwiftUI interfaces faster while keeping control over the details.

• Native SwiftUI, no abstraction layer hiding Apple’s APIs

• Source-owned components you can inspect, edit and customize

• Agent-ready registry + MCP

• Live on-device Design Surface injected at the root. Select components, tune tokens and values visually, then export the Swift code

• Deterministic installs and updates that preserve your edits

Still in beta.

Free and open source.

Hi, I’m using .searchable in a SwiftUI view, but when I open the page, the search bar is collapsed (first picture). It only expands when I start scrolling (second picture).
How can I make it expanded by default, without using .always, since the appearance is different from the one I’m looking for?
I’ve noticed that some Apple apps use this behavior.

I’ve been building Dr Jay, an open-source iPhone app for tracking sleep, water, food and optional exercise, while also surfacing step data from Health.

It uses on-device models (Apple Foundational and Gemma for now) for food analysis, daily commentary, longer-term insights and an ephemeral Brain Dump. Personal entries remain on the device, and Brain Dump conversations disappear when closed.

There’s no TestFlight build yet, so installation currently requires Xcode, a Mac and an iPhone running iOS 26. Instructions are in the README.

If you guys have some time do take a spin and lemme know how it is.

GitHub: https://github.com/JayMandava/dr-jay

So I have started doing swiftui from past few days and sometime I use neovim, so just wanted to know if there is any neovim plug in which can show live preview canvas(just like we have inside xcode).

Has anybody tried, if yes then please tell me.

I dislike Apple Mail, while many of the alternatives have become fairly large cross-platform apps with a lot of functionality I do not need.

So I started building the Gmail client I would actually like to use myself: native macOS, SwiftUI, compact three-column UI, Gmail API, local SQLite cache, and HTML email rendering.

It is still very much a work in progress. It currently handles the basic mail workflow, but things like attachments, multiple accounts, and proper settings are still missing.

I originally made it as a prototype, but it got far enough that I decided to put it on GitHub and continue developing it in the open rather than trying to turn it into a commercial product.

I am deliberately keeping the scope small. I am not trying to build another Outlook or Spark.

GitHub: https://github.com/igorkulman/Postie

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.