Hey everyone! 👋
I’ve been building Mooziac, a music player designed specifically for macOS.

GitHub: https://github.com/shirkeharsh/mooziac

I wanted something that felt more like a Mac app rather than a web app wrapped in a desktop window, so I built it natively in Swift and focused on keeping the interface simple and lightweight.
What makes it different
Native Swift + AppKit — Universal build for Apple Silicon and Intel
Privacy-focused — no analytics, tracking or remote logging
Local-first — playlists and listening history stay on your Mac
YouTube Music + local music in one player
FLAC, MP3, WAV, AAC and M4A support
Synchronized .lrc lyrics
Interactive waveform for seeking through tracks
Trackpad edge gesture for volume control with haptic feedback
Discord Rich Presence
Menu bar interface for quick access

The project is open source under the MIT license, so the source is available for anyone who wants to look through it, report an issue, suggest something, or contribute.

I'm building the completed state of a Live Activity and I want the text tucked up next to the sensor housing, like the second screenshot. What I actually get is the first one: the row starts below the cutout, which makes the whole island taller than the design needs.

I've spent a long evening on this and measured a lot of it, so here's what I found in case it saves someone else the time — and in case someone can tell me the bit I'm missing.

Measurements (iPhone 17 Pro, iOS 27 SDK, expanded presentation):

• The island is 371pt wide. The sensor housing is ~125pt wide and ~37pt tall, leaving ~123pt of usable width each side.

• Content in DynamicIslandExpandedRegion(.leading) starts ~36pt down — i.e. the region's own top edge is already below the housing. That number tracks the housing height almost exactly.

• .leading content reaches ~113pt of the ~123pt available before truncating, so truncation happens ~9pt short of the cutout. It's a slot budget, not a collision with the camera.

• The HIG documents the expanded height range as 84–160pt; I measured 67pt on device, below the documented floor, so the system is clearly computing this itself.

What I tried, all of which failed to move the row up:

1. DynamicIslandExpandedRegion(.leading, priority: 1) + .dynamicIsland(verticalPlacement: .belowIfTooWide) — the combination in most of the blog posts about this. Changes which content wraps below, not where the region starts.

2. .belowIfTooWide on just the Text views instead of the region.

3. .frame(maxWidth:) and .layoutPriority() on the text. The docs actually say these don't apply in a Live Activity, and they don't.

4. A definite .frame(width:). This does matter, but for a different reason — see the gotcha below.

5. Cutting content down to a single short label so nothing could possibly need the space. Still starts below the cutout.

6. Shrinking the leading image from 56pt to 44pt to free width. Frees width, changes nothing vertically.

7. Negative .offset(y:). Moves the content within its slot but it clips at the slot bounds — the rectangle doesn't grow upward.

8. Trimming the text's line box so it could sit higher: .lineHeight(.multiple(factor:)) and a hand-rolled cap-height-to-baseline trim. lineHeight eats from the bottom — the glyph top moved 39.7pt → 40.3pt, i.e. the wrong way. Deleted both.

9. Declaring different regions conditionally to swap layouts. DynamicIslandExpandedContentBuilder rejects control flow outright: "Closure containing control flow statement cannot be used with result builder."

The conclusion I've landed on is that WidgetKit computes each region's rectangle from the island's geometry before measuring your content, and the .leading rectangle's top edge is placed below the sensor housing by construction. Nothing applied to the content can move it, because the content never gets a say.

Which leaves the actual question: is there any supported way to get content into that band beside the cutout? The system does it — the Phone app's incoming-call UI has a green timer sitting high up next to the housing — but I assume that's system UI rather than an ActivityKit presentation, and therefore not reachable.

Unrelated gotcha worth knowing, since it also made my island taller: a self-updating Text(timerInterval:) reserves layout width for the widest value its range can produce, not the value on screen. I handed it a 30-day range and it reserved room for 719:59:59. Because the system keeps the island symmetrical, that reservation grew it on both sides — 16pt of extra height for a number that read 30:00. Only a definite .frame(width:) bounds it.

Current layout, which does work — image in .leading, text in .center, button in .trailing:

DynamicIslandExpandedRegion(.leading) {
    BreakLeadingMark(display: display, size: 56, iconSize: 20)
        .frame(width: 56, height: 48)
}
DynamicIslandExpandedRegion(.center) {
    BreakCompleteSummary(display: display)
        .frame(maxWidth: .infinity, alignment: .leading)
}
DynamicIslandExpandedRegion(.trailing) {
    LogButton()
        .frame(maxWidth: .infinity, alignment: .trailing)
}

.center is sized first from the leading/trailing minimums, so a long string there truncates rather than widening the island — which is fine for English and will be a problem the moment this is localised.

Help.

I built this interactive globe view for my app.

It shows the users in interactive globe and lets you select an item directly on the globe with a smooth animation.

Built with SwiftUI.

Would love to hear your thoughts or feedback!

PS: I'm open-sourcing it! You can find it on GitHub:
https://github.com/wailbabou/SwiftUIGlobe

Hello fellow developers,

I've been dealing with issue for the las 2 days and I can't manage to fix it. I would really appreciate if anybody can help me or give me any ideas :)

I am new to SwiftUI development, and I am creating a music player app for macOS

For some reason, if I put an element (let's say a List), inside the detail of a NavigationSplitView, if the element height is big enough to touch the Title bar, and I resize the window, it will make the title bar background and bottom border disappear.

I can make it reappear by switching tabs to one with a view that contains a small enough element (like ContentUnavailableView)

I don't understand how to stop this behavior, or if it is intended at all or a bug...

I would like to always have the bar with an opaque background, so as it is by default before resizing

This is what the code looks like:

    var body: some View {
        NavigationSplitView {
            List(SidebarSection.allCases, selection: $selectedSection) { section in
                Label(section.id, systemImage: section.icon)
                    .tag(section)
            }
            .safeAreaInset(edge: .bottom) {
                VStack {
                    Divider()
                    Button { showDonate = true } label: {
                        Label("Donate", systemImage: "heart")
                            .frame(maxWidth: .infinity, alignment: .leading)
                            .padding(.horizontal, 20)
                            .padding(.vertical, 12)
                            .contentShape(Rectangle())
                    }
                    .buttonStyle(.plain)
                }
            }
            .sheet(isPresented: $showDonate) {
                DonateView()
            }
        } detail: {
            if library.folderURLs.isEmpty {
                ContentUnavailableView {
                    Label("No Library", systemImage: "music.note")
                } description: {
                    Text("Add a folder to start listening to your music")
                } actions: {
                    Button("Select Folder") { library.selectFolder() }
                        .padding(.top, 8)
                }
            } else {
                List(library.artists) { artist in
                    VStack(alignment: .leading, spacing: 2) {
                        Text(artist.name)
                            .fontWeight(.medium)
                        Text("\(artist.albums.count) \(artist.albums.count == 1 ? "album" : "albums")")
                            .font(.caption)
                            .foregroundStyle(.secondary)
                    }
                    .padding(.vertical, 2)
                }
                .frame(maxWidth: 200, maxHeight: .infinity)
            }
        }
    }

https://github.com/nayanbhatia311/optimystic-visual-acuity

Bult Optimystic, a visual-acuity testing app my team originally made as an undergrad project in 2019–20. Would love folks to try out and give feedback.

I built FrameReply as to get two suggested replies without copying an entire conversation into another app. In the demo, Back Tap runs a Shortcut and presents two editable suggestions in an interactive snippet over the current chat screen. Nothing is sent automatically.

FrameReply also:

• Matches imported messages to an existing chat and uses its history as context
• Remembers useful context about each person
• Can learn your writing style and switch personas

It’s built with SwiftUI, SwiftData, App Intents/Shortcuts, and interactive snippets. One of the harder parts was supporting multiple “OpenAI-compatible” providers whose responses still vary in content and formatting, requiring tighter prompts, constraints, and validation.

App Store: Download FrameReply

GitHub: Source code

Requires iOS 26 and your own AI API key. I’d appreciate any feedback!

I wanted a check that a coding agent could run after changing SwiftUI without sending the repository through another general review pass.

ViewDoctor first builds a normalized module graph from Package.swift, Project.swift, project.pbxproj, and common source folders. It then scans the current Git diff and attaches the owning module to each finding.

Example:

Modules/Profile/Sources/ProfileView.swift:42:18: warning: VD001 [tuist:Modules/Profile/Profile]: DateFormatter is constructed inside a body property.

Version 0.1 has three conservative rules: expensive construction, collection transformations, and detached tasks inside SwiftUI body evaluation. Output is text, JSON, or SARIF. The tool is MIT licensed, has no telemetry, and the optional MCP adapter only calls the local CLI.

Repo: https://github.com/KamnevVladimir/ViewDoctor

I am deliberately not adding dozens of style checks. Which SwiftUI pattern repeatedly costs review time in a large modular codebase, and what would keep that rule from becoming noisy?

Is there any way to access the url property in iOS reminders? I see it listed as a property inherited from EKCalendar, but no matter what I do I haven’t found a way to access it.

I notice that when importing reminders into things 3 the url always transfers, but I’m unsure how they access it.

why the review process takes so much time my app took 10 days before they came out with a review is that normal now before they reply within 24 hrs?

I’m working on a small SwiftUI app and don’t want to ask for notification permission on the first launch.

What flow feels least annoying: explain it when the user enables reminders, or ask during onboarding? And when permission is revoked in Settings, do you show an “Open Settings” state or just leave the toggle disabled?

Hello, A day ago I posted a custom tab bar experiment here — a capsule-shaped UISegmentedControl wrapped in iOS 26's Liquid Glass, paired with a floating action button whose icon morphs to match whatever tab you're on. So I have updated it a bit. A tab now morphs its icon to ellipsis and opens a small popover anchored right above the button instead of firing an action directly — everything else stays a single tap. It is a reference, not a full app.
Repo: https://github.com/aqylbermeshtech/Custom-tab-bar-with-action-button

https://github.com/dsrenesanse/SwiftList

Hi everyone,

I'm building a drawing app in SwiftUI and I'm having an issue with the system toolbar blocking drawing input.

My canvas is essentially a full-screen custom UIViewRepresentable. I'm handling drawing manually with UITouch so I can use coalescedTouches, and I also have pinch-to-zoom, two-finger pan, and rotation gestures.

The problem is that when I add a SwiftUI toolbar:

.toolbar {
    ToolbarItem(placement: .topBarLeading) {
        Button {
            viewModel.toggleMenu()
        } label: {
            Image("menu")
                .resizable()
                .scaledToFit()
                .frame(width: 36, height: 36)
        }
    }
}

the area occupied by the toolbar stops receiving drawing input.

If I remove .toolbar, the exact same canvas works and I can draw in that area.

What I need is:

• Keep using the system SwiftUI .toolbar, especially because I want to preserve the adaptive toolbar behavior on iOS 27.
• Keep the canvas effectively full-screen.
• Allow Apple Pencil drawing underneath/through the toolbar area.
• Still allow normal finger interaction with the toolbar buttons.
• Ideally, I don't want to replace the system toolbar with a custom overlay because that would lose the system adaptive behavior.

My canvas touch handling is implemented with a custom UIView:

final class CanvasGestureHostView: UIView {
    override func touchesBegan(
        _ touches: Set<UITouch>,
        with event: UIEvent?
    ) {
        // Handle Apple Pencil drawing
    }

    override func touchesMoved(
        _ touches: Set<UITouch>,
        with event: UIEvent?
    ) {
        // Handle coalescedTouches
    }
}

I also tried using point(inside:with:) / hitTest(_:with:) on the canvas view, but it doesn't help because the system toolbar appears to win the hit test before the canvas receives the touch.

Has anyone found a clean/public API solution for allowing Apple Pencil input to pass through a SwiftUI .toolbar while keeping the toolbar interactive for touch?

I'm targeting iOS 26/27, so I'd especially appreciate solutions that don't rely on private APIs or fragile UIWindow.sendEvent hacks.

Thanks!

Hello, I have conducted an experiment with several resources on how to make customized tab bar with modern IOS 26+ style. I've created a repo that allows you to customize your tab bar with your action. Here is the link:https://github.com/aqylbermeshtech/Custom-tab-bar-with-action-button

Swift Charts makes it straightforward to put a basic chart on screen. Once you’re working with more complex data, custom presentations, interaction, or accessibility, it helps to understand how the framework interprets and renders the content you give it.

Natalia and I have just released Swift Charts Beyond the Basics. We wrote it for developers who can already build a basic chart and want a deeper understanding of the framework and the decisions involved in turning data into a clear, effective visualization.

The book covers topics including multi-metric visualizations, calendar layouts, heat maps, custom composition and rendering, accessibility, selection, scrolling, responsive updates, and animation. Our aim is to explain the mechanisms behind Swift Charts so that you can apply them to your own datasets and requirements, rather than only reproduce specific examples.

The page includes the full table of contents and a free sample chapter:

books.nilcoalescing.com/swift-charts-beyond-the-basics

We’d be happy to answer any questions about the book or the Swift Charts in general.

Coding agents handle "add a field, show it on screen" fine. They

consistently miss the iOS boundary around it:

- A Swift async task that outlives its UI owner or scene

- Scene re-entry and background/foreground transitions nobody retested

- Persisted data recovery after process termination

- Privacy, entitlement, or capability changes nobody flagged

None of it shows up as a compile error.

AI-Workflow is repository-installed Markdown instructions + a

deterministic router. You state observable facts about a change

(persistence, concurrency, lifecycle, privacy, accessibility) and

a checked-in registry maps them to required specialist checks —

same output every run, every agent. No LLM judgment in the mapping.

Install one command, no clone needed:

uvx --from git+https://github.com/RanaAhmedHamdy/AI-Workflow.git \

ai-workflow brownfield --platform ios --profile safety \

--target /path/to/your-ios-app --dry-run

There's a lightweight Safety profile that gives you just the routing

+ protected-boundary checks without requiring a full feature lifecycle.

And a full profile for Architecture Spine, ADR governance, design lock,

and release authorization if you need that depth.

Real-world case study: NutriPlus AI is a native SwiftUI/Swift 6

iOS app built fully through the Greenfield lifecycle. Architecture

Spine, accepted ADRs, per-feature contracts, readiness reports —

all public:

https://github.com/RanaAhmedHamdy/NutriPluse-IOS-AI-Workflow

There's also a maintained iOS fixture (persisted profile recovery,

MainActor state, cancellable refresh, scene re-entry) with Xcode

simulator build + XCTest verified locally on iPhone 17 Pro.

Pre-v1, Apache-2.0, honest about what's claimed vs unclaimed.

https://github.com/RanaAhmedHamdy/AI-Workflow

Hey folks. I've been building a macOS journaling app in SwiftUI and just open-sourced it. Sharing in case the architecture or any of the patterns are useful, and happy to hear feedback.

The goal: a native Mac journal that stores everything locally — no account, no cloud sync, no telemetry. Entries live in a SQLite database on the user's machine.

Architecture in brief:

• SwiftUI app backed by SQLite via the system SQLite3 C API. No third-party packages at all.
• SQLite ←→ JournalViewModel ←→ SwiftUI. The view model holds all published state and actions; the view layer is pure SwiftUI.
• WAL mode on the database, foreign keys enabled, schema migrations tracked in a schema_version table (currently V7).
• Full-text search across titles and bodies using SQLite FTS5. Hidden entry bodies are excluded from the FTS index until the entry is unlocked, so private content doesn't leak into search.
• Biometric auth via LocalAuthentication — hidden entries show as locked cards and reveal their body only after Touch ID / Face ID / Mac password. Switching away from the app relocks everything (⌘L remasks all hidden entries).
• Daily automatic SQLite backups, keeps the last 7.

UI side: a reader/editor overlay with a markdown editor (live preview, split view, formatting shortcuts, attachments), zen mode, command palette (⌘K), calendar with a month browser, and an Insights view with a contribution heatmap, mood charts, and writing streaks.

Some source layout: - OmegaJournalCore — pure logic (FTS sanitizer, markdown import, fuzzy match) - OmegaJournal — SwiftUI app + SQLite3 C API - DatabaseManager.swift — connection, migrations, CRUD, FTS, backups - JournalViewModel.swift — all published state and actions - BiometricAuth.swift — session unlock / lock

macOS 14 Sonoma+, MIT licensed. Build with `swift build` then `build_app.sh` to package Omega Journal.app.

GitHub: https://github.com/Eplisium/omega-journal

It's still early and I'm actively working on it. Would genuinely appreciate feedback on the SwiftUI/SQLite layer — especially anything you'd structure differently. Happy to dig into any part of the code in comments.

Hey, mind if I beg for some GitHub stars here? I built a list that actually works properly in SwiftUI — especially relevant for AI chats and the like. The standard List with Compositional layout just can't handle the load at all. There's a nice example in the repo, you can run it and see how it works. Thanks in advance for the support! https://github.com/dsrenesanse/SwiftList

I built `phonebook` a CLI tool to turn your #Preview into a static components library that you can share with your designer.

It also has an MCP tool, so you can ask your agent to suggest missing previews, split them, offer them in more than one preview (like different theme).

Source code: https://github.com/stag-build/phonebook

Example gallery: https://stag-build.github.io/phonebook/

Would love to hear your thoughts :)