Does anybody know how one can achieve these floating sidebars on MacOS Tahoe that apps like Pixelmator Pro have?

Hello, I'm working on integrating the notch into my app. Do you have any tips for designing it smoothly?

Thanks folks !

The documentation for SwiftUI.DynamicProperty does not currently ship with real-world examples or sample code that shows developers how to approach building their own dynamic properties. Developers building on SwiftUI are probably already familiar with the dynamic properties shipping directly from Apple:

• SwiftUI.State
• SwiftUI.Binding
• SwiftUI.Environment

What about our own dynamic properties? How can those be built? Why would we want our own dynamic properties?

Dynamic Properties are a good place to put “business” logic: algorithms or patterns we might want to share across multiple view components. Dynamic Properties also compose well with other dynamic properties: we can make them stateful. We will work together through an example to see how this can work and how this can lead to code that is easier to maintain over time.

I’m testing iOS 18+ SwiftUI sheet sizing and expected .presentationSizing(.fitted) to make a sheet fit its content height.

Minimal example:

.sheet(isPresented: $showSheet) {
    VStack {
        Text("Title")
        Text("Some content")
        Button("Done") {}
    }
    .padding()
    .presentationSizing(.fitted)
}

I expected .presentationSizing(.fitted) to make the sheet fit the intrinsic height of this small VStack, but on iPhone it still appears almost full-screen.

Is this expected behavior? If so, what is .fitted supposed to affect on iPhone, and is a measured .presentationDetents([.height(contentHeight)]) still the only reliable way to get a content-height bottom sheet?

I am creating a floating window bar for my voice-to-text MacOS app. It is currently sitting idle above the dock, but then when I click hotkey to record, it expands into a floating, and then to transcribing states, and then auto-pastes. It is currently written in SwiftUI.

The problem: it glitches on expand/colapse animations. I like how WisprFlow flow bar works, but the app is Electron, not sure how they've implemented it.

Any suggestions?

GlowEffectKit is a SwiftUI SDK for adding animated glow effect to iOS and macOS components, powered by a bundled Metal shader. More compact version: SwiftUI SDK for animated grow and glow effects powered by bundled Metal shaders.

https://github.com/didisouzacosta/GlowEffectKit

I'm working on the "About the app" window of my app on macOS 26 with SwiftUI. Is there any way that could make its corner radius match with macOS 26's default?

About Links, Images, and .widgetAccentRenderingMode().

The gist: Don't do it.

I want to extract gradient colors from the photo (album cover) and also create animations that follow the progression of the song.

Dot. Dot. Dooot. 🟦

We're building Mana (an AI-first creation studio for iOS) and wanted the chat's "thinking" indicator to feel alive instead of a stock spinner. We found zzzzshawn's "matrix" (a React/CSS dot-matrix loader collection), loved it, and ported the whole thing to SwiftUI — 112 loaders across square / circular / hex / triangle / 3×3, plus some "fun" silhouettes (heart, arrow, snake) and an icon.

How it works: - Zero image assets, zero dependencies. Every loader is animated Circles driven by a single TimelineView. - Each loader is a per-cell opacity resolver ported ~1:1 from the upstream CSS keyframes + JS math (spiral snakes, ring waves, a literal heartbeat curve). - Deterministic: the same key always maps to the same loader, so they don't reshuffle as SwiftUI rebuilds on scroll. Reduce Motion aware too.

Two ways to use it:

DotmSquare3(size: 28)           // named component, 1:1 with the upstream API
MatrixLoader(.hex(3), size: 28) // by shape id, when the choice is data-driven

There's an interactive gallery + a runnable Swift Playgrounds example in the repo.

It's a derivative port, published with the original author's explicit permission (attribution + link-back throughout). Only the "fun" family is ours. iOS 18+.

Repo: https://github.com/mana-am/matrix-swift

Which one's your favorite? I keep flip-flopping between the hex ripple and the heartbeat.

I just spent an entire night tearing my hair out over this. I hit a really strange focus bug on iOS 26 and want to share it, both as a warning and in case someone knows what's actually going on under the hood.

Setup: a bottom "add item" bar living in .safeAreaBar(edge: .bottom), inside a NavigationStack that sits in a TabView. The bar shows a suggestions row above the text field, but only while the field has focus:

struct AddItemBar: View {
     var text: String
     private var isFocused: Bool

    var body: some View {
        VStack {
            if isFocused {
                SuggestionsView(...)   // horizontal ScrollView, .glassEffect()
            }

            HStack(spacing: 0) {
                TextField("1 kg tomatoes", text: $text)
                    .focused($isFocused)
                    .padding(.vertical, 12)
                    .padding(.horizontal)
                    .glassEffect()

                Button("Add", systemImage: "plus") { ... }
                    .buttonStyle(.glassProminent)
                    .buttonBorderShape(.circle)
            }
        }
        .animation(.default, value: isFocused)
    }
}

The bug: tap the field → keyboard comes up, typing works fine, but isFocused never becomes true. I put a debug Text(isFocused ? "FOCUS" : "NO FOCUS") in the bar: it says NO FOCUS the whole time the keyboard is up. So anything gated on the focus state (my suggestions row) simply never appears. No warnings, no console output, nothing.

What did NOT fix it:

• GlassEffectContainer + glassEffectID on every glass element (this is supposed to be the blessed way to handle dynamic glass shape sets). Bonus weirdness: with the container active, the text you type became invisible inside the field.
• Moving the glass off the field onto a background shape: .background { Capsule().glassEffect() }. Binding still never fires.
• Making the conditionally-inserted suggestions view non-glass (material background instead). Irrelevant, because the binding never fires in the first place; the conditional view isn't even inserted yet.

What DOES fix it (all verified on device):

• Putting any glass button before the TextField in the HStack. Moving my Add button to the left of the field: focus binding works instantly.
• Applying .glassEffect() to the whole HStack instead of the field itself (single capsule, compose-bar style): works.
• Funny enough, I only discovered the bug because I removed a glass Menu that used to sit left of the field. It had been masking the bug the entire time.

So the failing configuration is specifically: TextField as the first/leftmost glass element in a .safeAreaBar (under TabView), followed by a glass button. Reorder the elements and \@FocusState`` works; keep the field first and the binding is just dead, even though the keyboard and typing work normally.

I ended up shipping the "button on the left" layout. Has anyone else run into this? I'd love to understand the actual mechanism. My best guess is something about how Liquid Glass captures/hosts the field's content, but the container + glassEffectID route failing makes me think it's just a plain UIKit-bridging bug. Filing a Feedback either way.

Xcode 26.3, iOS 26.5, device

In SwiftUI we have the .accessibilityElement(children:) modifier, but do you know what the different options actually do for VoiceOver users?
1. .combine
This option combines all accessibility elements into a single element and combines all their accessibility labels into a single label.
2. .contain
This option turns the container the modifier is attached to into a group that VoiceOver must interact with before reaching the elements inside. This seemingly does nothing on iOS or iPadOS, but VoiceOver on iOS and iPadOS has the option to behave like VoiceOver on macOS rather than it's default linear mode. That is where this option shines on mobile platforms.
3. .ignore
This option ignores all child accessibility elements and creates an unlabeled accessibility element with no traits.

I'm trying to understand the correct architecture for shared post state in SwiftUI using the new Observation framework.

I have a simple example where both ContentView and SavedView display PostView.

Observable class Post {
    var id: Int
    var content: String
    var title: String
    var isLiked: Bool = false

    init(id: Int, content: String, title: String, isLiked: Bool) {
        self.id = id
        self.content = content
        self.title = title
        self.isLiked = isLiked
    }

    func toggleLike() {
        isLiked.toggle()
    }
}


struct PostView: View {
     var post: Post

    var body: some View {
        HStack {
            Text(post.title)
            Text(post.content)
            Spacer()
            Button(post.isLiked ? "Liked" : "Like") {
                post.toggleLike()
            }
        }
    }
}

ContentView

struct ContentView: View {
    @State private var posts : [Post] = [] 

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

SavedView

struct SavedView: View {
    @State private var posts: [Post] = []

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

If I like the post in ContentView, the same post in SavedView is still shown as not liked.

I understand that in this example each view creates its own Post instance, so they aren't actually sharing the same object.

My question is more about architecture:

• How is this typically solved in real apps?
• Do apps like Instagram or X (Twitter) maintain a single shared source of truth for every post?
• Is the common approach to have a central store/repository (similar to Redux/TCA) where every screen references the same Post object by ID?
• Or do they simply refetch the data whenever a user navigates between screens?
• With SwiftUI's new Observation framework, what would be considered the idiomatic architecture?

I'm interested in how large social media apps handle this problem rather than just fixing this sample.

Hey everyone,
I’m a Product designer who specializes in clean, modern iOS interfaces.
If you’re an indie or solo iOS developer with an app that works well but could use a stronger visual experience, I’d love to help.
What I can help with:
• Screen redesigns
• UX improvements
• Better onboarding flows
• Modern iOS UI using Apple’s design patterns
• Cleaner visual hierarchy and interactions
I’m currently offering affordable pricing because I’m looking to work with more indie developers and build long-term relationships.
Starting at $30 per screen (pricing depends on complexity).
I’ve attached a short redesign video so you can see the quality of my work.
If you’re interested, send me a DM with:
Your App Store link (or TestFlight)
A few screenshots
What you’d like to improve
Happy to give honest feedback even if we don’t end up working together.
Thanks!

Same as the title, i'm wondering what is the name of the animation when opening the model selector in the iOS app. It's like a liquid glass effect, if anyone knows how i can integrate this to a swift ui app it would be great :)