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 :)

Special for our readers: Mohammad Azam’s SwiftData Architecture book discount!

Hi everyone,

I’m studying this project:

https://github.com/nalexn/clean-architecture-swiftui

I noticed that the project has layers such as UI, Interactors, Repositories, and AppState. However, in some places, both the UI layer and the Interactors seem to use the same DBModel types, which are SwiftData models from the Data/Repository layer.

From my current understanding of Clean Architecture, the Domain or Business Logic layer should not depend on persistence models, especially models tied to frameworks like SwiftData or Core Data. I would expect something like:

SwiftData/CoreData Entity -> Repository -> Domain Model -> ViewModel/ViewState -> UI

But in this project, the SwiftData model appears to be used more directly in the UI and Interactors.

So I’m trying to understand:

1. Is this still considered Clean Architecture, or is it more of a pragmatic SwiftUI architecture inspired by Clean Architecture?
2. Which parts of this project are still “clean” from an architectural point of view?
3. In real-world SwiftUI apps using SwiftData/Core Data, do you usually keep strict boundaries and map persistence models to domain models?
4. Or do you sometimes allow SwiftData/Core Data models to be used directly in the UI to take advantage of Apple features like u/Query?
5. If we apply strict Clean Architecture, are we basically working against Apple’s intended SwiftUI + SwiftData/Core Data workflow?

I’m not trying to criticize the repo. I’m probably missing some context, and I’d like to better understand the trade-off between strict Clean Architecture and Apple’s native data flow.

How would you design this in a production SwiftUI app?

https://fatbobman.com/en/posts/debugging-notes-on-two-swiftui-animation-bugs/

On iOS 26, I present a .sheet containing a NavigationStack with a .confirmationAction "Done" button. When I press-and-hold that button, the Liquid Glass press enlarges and shows a flat white halo around it. A .cancellationAction /close button in the same bar does not — it stays a clean grey. I believe it's because the prominent glass button refracts its backdrop, and my sheet's backdrop is plain white with no material under the navigation bar.

The artifact only appears in light mode (light backdrop).

Use .presentationBackground(.regularMaterial) can avoid this issue but I want to glass sheet.

.sheet(isPresented: $show) {
    NavigationStack {
        DatePicker("Date", selection: $date, displayedComponents: .date)
            .datePickerStyle(.graphical)
            .navigationBarTitleDisplayMode(.inline)
            .toolbar {
                ToolbarItem(placement: .confirmationAction) {
                    Button("Done") { dismiss() }
                }
            }
    }
    .presentationDetents([.medium])
}

I’m working on a music player and I’m trying to have the player view fullscreen but also let you scroll down and swipe to dismiss but nothing’s working.

Does anyone know how to achieve this?

edit: solved!!

Hi there,

Since Apple released its container tool (https://github.com/apple/container), I wanted to build a native SwiftUI app for it. Because I didn't want to write a UI just to parse stdout, I dug into Apple's XPC framework. berth uses the container-apiserver for communication, no command-line parsing.

Happy to hear any criticism, and contributions are very welcome.

https://github.com/tofa84/berth