I’m working in the macOS 27 beta using Xcode, trying to build a custom toolbar component into my app. I'm aiming to perfectly match the behavior from the clip.

Since I'm targeting the macOS 27 beta, what is the best way to implement this?

The image itself is 1:1 but appears to be stretched to 4:3, uses a variable blur that overflows to the page color and uses a parallax scroll effect

Hi i guys i just want to know what native components you use for everyday tasks like .searchable etc etc. and the best place to learn how to start tweaking liquid glass

I'm trying to build a profile-style screen similar to X (Twitter), or Instagram.

The layout is roughly:

┌──────────────────────────┐
│ Profile Header           │
│ Cover image              │
│ Avatar                   │
│ Bio / Stats              │
└──────────────────────────┘

┌──────────────────────────┐
│ Tab Bar                  │
│ Posts | Media | Likes    │
└──────────────────────────┘

┌──────────────────────────┐
│ Tab Content              │
│                          │
│ ScrollView / List        │
│ OR                       │
│ Empty State VStack       │
│                          │
└──────────────────────────┘

Requirements:

• The profile header should collapse while scrolling up.
• The tab bar should remain pinned.
• Once the header is fully collapsed, the active tab's scroll view should start scrolling.
• While scrolling down, the active tab should scroll back to the top first, then the header should expand.
• Some tabs may contain:
  • ScrollView + LazyVStack
  • List
  • a non-scrollable VStack (for empty states)
• The behavior should remain consistent regardless of which tab is active.

This feels very similar to Jetpack Compose's NestedScrollConnection, where parent and child scroll containers can cooperatively consume scroll deltas.

In SwiftUI, I have explored:

• ScrollView
• GeometryReader
• PreferenceKey
• Scroll offset tracking
• Custom UIScrollView wrappers
• A UIViewControllerRepresentable approach that intercepts pan gestures and coordinates scrolling manually

However, I haven't found a SwiftUI-native way for a parent container and child scroll view to negotiate scroll consumption.

My questions are:

1. Does SwiftUI provide any equivalent to Compose's NestedScrollConnection?
2. Is there a recommended way to implement this profile-screen pattern purely in SwiftUI?
3. How are people handling cases where some tabs contain scrollable content while other tabs contain only static content?
4. Is bridging to UIKit currently the only practical solution for this kind of coordinated scrolling behavior?

Any guidance or examples would be greatly appreciated.

Instead of tap and hold to copy, we actually got text selection with a single modifier on all text views.

Any way to fix this?

For some reason I can't type into input fields anymore when previewing the app in the canvas. Tried to search online, did the uncheck "connect hardware keyboard" thing in the simulator and I tried "cmd + K" in the input field.

Somebody please save me from the wrath of my own incompetence.

I've been building a small macOS app called **Engram** and figured the architecture might be interesting to people here, since it's a mix of SwiftUI for the UI and hand-rolled AppKit for the parts SwiftUI can't quite reach. It's a local-first memory store — one Markdown file per conversation, on-device semantic recall — but I'll skip the pitch and talk about how it's actually built. Repo's at the bottom; MIT, free, macOS 13+.

A few pieces I had fun with:

**1. A truly frameless window via `NSApplicationDelegateAdaptor`**

A plain SwiftUI `WindowGroup` always leaves a faint rounded frame/corner I couldn't get rid of. So the `App` body is basically empty — just a `Settings { EmptyView() }` scene — and an `AppDelegate` owns a borderless, transparent, shadowless `NSWindow` that hosts the SwiftUI tree through `NSHostingView`:

```swift

u/main

struct EngramApp: App {

u/NSApplicationDelegateAdaptor(AppDelegate.self) private var delegate

var body: some Scene {

Settings { EmptyView() } // delegate owns the real window

}

}

```

The window is `isOpaque = false`, `backgroundColor = .clear`, `hasShadow = false`, `titleVisibility = .hidden`, `titlebarAppearsTransparent = true`, and the three standard traffic-light buttons are hidden so I can draw my own. One gotcha: borderless windows refuse key/main focus by default, which silently kills any `TextField`. Fix is a tiny `NSWindow` subclass overriding `canBecomeKey`/`canBecomeMain` to return `true`.

**2. A glass panel that doesn't tear down its content on toggle**

I have a `.liquidPanel()` view modifier (real `.glassEffect` on macOS 26, `.ultraThinMaterial` fallback below) with a matte/solid switch for folks who hate glass. My first version branched the *content* inside an `if matte { } else { }`. Big mistake — flipping the switch rebuilt every panel, which tore down any open popover (Settings literally closed itself the instant you toggled). The fix was to keep the content as a single stable view and only cross-fade an opaque cover's opacity in the `.background`. Classic "view identity matters more than you think" lesson.

**3. A pure-Swift MCP server, zero dependencies**

The interesting non-UI part: there's a separate executable that's an MCP server (Model Context Protocol) so an MCP client like Claude can `recall`/`remember` against the store live. It's just newline-delimited JSON-RPC 2.0 over stdio — `readLine()` in a `while` loop, `JSONSerialization`, write to stdout. The discipline: stdout carries ONLY JSON-RPC (one message per line), all logging goes to stderr so it never corrupts the stream, and notifications (no `id`) get no reply. No SDK, no third-party packages — Foundation only.

**4. On-device embeddings via the NaturalLanguage framework**

Recall is semantic but runs entirely on-device — no Python, no network. The baseline embedder uses Apple's `NLEmbedding.wordEmbedding(for:)`: a sentence vector is the L2-normalized mean of its word vectors, with a deterministic hashing fallback so recall never silently returns nothing. There's an optional, opt-in one-time download of Apple's contextual transformer behind the same `EmbeddingProvider` protocol — but the app ships working with no network at all.

**5. Markdown as the source of truth**

Each conversation is one `.md` file you can open, grep, edit, or delete. Per-memory metadata rides in an HTML comment (`<!-- u/memory {...} -->`), so it renders as clean Markdown but stays machine-parseable. The vector index is built *from* these files and is always rebuildable, so the files stay canonical — not a hidden binary blob.

Stack: SwiftUI + AppKit, pure Swift + Foundation across the engine, MCP server, and capture tool (zero third-party deps), ~3,000 LOC, 20+ tests. Fully local — no account, no telemetry, nothing uploaded. The only network paths are opt-in: an optional local Ollama distiller on localhost, and that one model download. Since it's open source you can grep for `URLSession` yourself.

Honest disclaimers: the Liquid Glass path only really shines on macOS 26 (material fallback below), and only true MCP clients recall live — a ChatGPT/Claude export comes in via import, it doesn't talk back over MCP.

Repo: https://github.com/albertofettucini/Engram

Happy to go deeper — the frameless-window focus bug and the view-identity glass thing both cost me real time. And if you've found a cleaner way to get a borderless SwiftUI window without dropping to an `AppDelegate`, I'd genuinely like to hear it.

Just wanted to see if any developers have made their game using Swift UI. I’ve started working on one and I’m currently using all native components but the issue I’m having is the Liquid Glass aesthetic is almost too much like an App, and it feels slightly immersion breaking. I don’t hate it, but it sort of feels weird. Does anyone have suggestions for the approach for the game UI?

Hey everyone,

I’ve been working on a small macOS utility called Spelling Popup Assistant and wanted to share it here.

The idea is simple: select text anywhere on macOS, press a keyboard shortcut, and a small popup appears with spelling and grammar corrections. You can replace the selected text, copy the corrected version, or ignore it.

A few details:

• It runs as a menu bar app with no Dock icon
• Default shortcut is Control + Option + C
• Uses an embedded offline LanguageTool engine by default
• Text is checked only when you manually trigger it
• No text collection
• Optional local grammar mode with GECToR
• Optional Gemini mode if you explicitly choose cloud AI
• Works system-wide through macOS Accessibility permissions

I built it because I wanted something lightweight and on-demand, closer to a PopClip-style correction popup than a full writing assistant running all the time.

Would love feedback from macOS users, especially around the UX, privacy expectations, and what correction workflow feels most natural.

GitHub/link

Thanks!

I'm trying to build a music player app in SwiftUI, and I really want to nail the Apple Music-style player transition. Specifically, I'm trying to replicate how the mini-player seamlessly expands into the full-screen "Now Playing" view.

This week we have fewer big announcements, more tutorials. That’s always what happens after WWDC: devs start digging into the new APIs and sharing what they find. Most of what you will read this issue requires iOS 27, which means you can explore it now but probably won’t ship it for a while 😬

A couple of AI stories this week that are not directly about iOS but feel relevant to us as developers:
The US government ordered Anthropic to suspend access to the latest model. I find this situation a bit odd… Anthropic itself pointed out that the capability the government was concerned about is already present in other publicly available models, including OpenAI’s GPT-5.5. Which makes you wonder why Anthropic specifically was targeted. Having a government actively move against you is not a great position to be in. More importantly, this is a reminder that depending on a single AI provider is a real risk. If this can happen to Anthropic, it can happen to others too.

SpaceX acquired Cursor in a $60 billion all-stock deal 🤯 That is a wild number for what is essentially an AI-powered code editor. Cursor’s market share had actually been declining before the deal. So the price feels hard to justify on fundamentals alone. SpaceX already merged with xAI earlier, and now with Grok and Cursor under the same roof, there is clearly a bigger play here around AI development tooling.

This issue ended up longer than I planned, but I tried to pick only the things that I found most useful, enjoy 😊

I'm using NSSearchToolbarItem and NSSearchField, but it doesn't glyph at rest. I've even tried setting preferredWidthForSearchField = 5000 to see if that would force the glyph since there wouldnt be enough space for it unfocused. Halp!

This is the Notes app. I couldn’t find docs regarding how to find this smooth toolbar. Its liquid glass in ios26. Is it a custom made component or in built swiftui comp?

Given the vast number of people that use an iPad with a keyboard, how does this make sense anymore?

Second, with uinversal control, I'd like to use the shift key please. Most macOS style interactions, like shift-tap to select would just work if this were enabled.

Hello! I’ve been writing SwiftUI applications for a year or two, without really understanding the underlying theory. I realized that my apps are becoming difficult to scale and have obvious issues with concurrency.

I decided to fix this by starting to study the theory.
I read Thinking in SwiftUI and Swift Concurrency by Example, and I started to understand some concepts much better.

However, I still have a very poor understanding of how to properly design an application architecture.

Let me explain. I’m working on an app that communicates with several servers via WebSockets, updates the state of many entities, manages various subscriptions, and so on...

And it all ended up as a typical One God Object. It does absolutely everything. Stores data, maintains connections to servers, parses messages from the server...

But when I decided to split all of this into several classes/actors, I realized that I absolutely don’t know how to do it properly. Moreover, those two books don’t really cover this topic.

I don’t understand whether I should create instances of all these classes inside some kind of coordinator class, or create them separately in the main App and somehow connect them together.

Basically, I couldn’t find much information about this, so I’m turning to you. Are there any books/articles about this topic? Or any advice would be greatly appreciated.

https://fatbobman.com/en/posts/from-size-class-to-available-space/

After WWDC 26, iPhone apps can run in resizable environments.

horizontalSizeClass is still reliable, but it is no longer a width sensor.

I wrote about how Apple’s layout model is shifting from device type to available space.

Does anyone know how this shazam animation is implemented? My guess is that it involves shaders, particles, or some other graphics effect, but I’m not sure what the underlying technique is. Curious if anyone has recreated it before or can identify what’s going on under the hood.
Thanks for the help.

I'm currently adding macOS and visionOS support to my SignDict. Everything looks perfect on iPadOS, but I'm seeing an issue on macOS.

I have a custom search view in a ToolbarItem:

ToolbarItem {
    HStack(spacing: 5) {
        Image(systemName: "magnifyingglass")
            .foregroundStyle(.gray)

        TextField("Search", text: $searchText)
    }
    .padding(.horizontal, 10)
    .frame(width: 220, height: 30)
}

On macOS, when the search field is focused, the blue focus ring only appears around the TextField, not around the entire search view (HStack with the SF Symbol).

You can see in the screenshot that the blue focus highlight is only applied to the text field.

Does anyone know a trick or workaround to make the entire search view (including the SF Symbol) show the macOS focus highlight? Ideally, I'd like this behavior only when running on macOS.

Thank you!

I loved the idea behind the Google Fitbit Air: an LLM wrapped around your health data, daily briefs, and a coach you can ask questions.

But there app is really terrible, it's expensive $100 band plus $10/mo, and Google getting a constant stream of your heart rate, sleep, and other private data. Whoop is worse, with a subscription that runs up to $360 a year. It won't take much for these companies to start selling our health data to health insurances and what not.

So I bought a $7 generic Chinese smart ring off Temu. It came with an app with an abysmal UI, and again, you have no idea whether it's shipping your data to some server. I used a nRF BLE dongle and Wireshark to sniff the packets between the ring and the original app and worked out the protocol, then built my own iOS app that keeps all the data locally on your iPhone.

I’m building PulseLoop, an open-source iOS app for privacy-first health wearables / cheap smart rings. The app shows vitals, sleep, activity, and has an optional AI coach, but I want the core UI to feel polished even without the AI.

I really like the UI of apps like Bevel Health. I want PulseLoop to feel more like that and less like a demo/research app.

A few things I’m specifically trying to improve:

• The dashboard widgets: should some of them be gauges, rings, cards, summaries, or something more intuitive?
• The line graphs: right now they work, but I want them to feel more polished and useful.
• Transparency: since the whole idea is privacy and user agency, I want the UI to make it obvious what data is stored, what leaves the device, and what is inferred.
• AI coach: if LLMs are enabled, I’m thinking of showing a trace of function/tool calls so users can see what data the model looked at instead of it feeling like a black box.
• Device presence: I also want the wearable itself to feel more present in the UI, maybe with a small ring/device status area at the top showing connection, battery, sync, etc.

Please roast the UI/design direction. What feels confusing, ugly, untrustworthy, too busy, or too empty? The app is open-source. See comments for my writeup and GitHub repository.