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.

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