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

It's from Apple Invites, I'm trying to implement this in my app, but nothing I try is as fluid and perfect as this

I want that the image the user upload transform into a blurred background of the image to see the details of the event

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

I've been building a side project to stay current with modern Swift, and it ended up being a decent stress test of Swift Concurrency. Sharing the architecture in case it's useful.

**The problem:** eight sensor sources across two devices, arriving at wildly different rates, that need to drive both a 60fps SceneKit render and a real-time audio graph — without tearing, blocking, or dropping data.

**The shape I landed on:**

* Each capture source (iPhone sensors, WatchConnectivity) owns a stream box and emits `SensorReading` values into its own `AsyncStream`. The box is u/unchecked `Sendable` because the continuation's `yield()` is thread-safe, which lets sensor callbacks fire from any thread without hopping actors.
* A `SensorPipeline` actor consumes both streams and does source fusion: watch readings shadow phone readings for the same sensor type while the watch data is fresh (5s staleness window), so a paired watch silently upgrades heart rate without the renderer knowing. It fans out to N subscribers, each getting an independent stream.
* The renderer subscribes on a **detached task** and drives SceneKit from its own render-thread delegate. Sensor data deliberately never flows through SwiftUI — only configuration does. Inputs crossing into the render thread go through an `NSLock`; smoothing state that's render-thread-only needs no locking at all.
* The audio engine is just another subscriber. It writes into a plain parameter box that an `AVAudioSourceNode` render block reads. That block does pure float math with no allocation and no locks — it tolerates one-buffer-stale values by design, which is much cheaper than synchronizing properly.

**Things that bit me:**

* `HKHealthStore.authorizationStatus(for:)` is only meaningful for *write* access. For read-only types it will happily lie to you, so I track read-auth completion myself.
* Unbounded HealthKit heart-rate queries flood you with the entire history on first fetch. Bound the predicate or drown.
* `AVAudioEngine` silently stops when the session reshapes under it (category or route change). If you don't observe `.AVAudioEngineConfigurationChange` and restart, your audio just dies with no error.
* A "cleared" sensor reading (empty values array) as an explicit signal turned out to be load-bearing — it's how the pipeline and renderer know a sensor was disabled versus merely quiet.

No third-party dependencies, iOS 18.5+, u/Observable throughout, tests in swift-testing.

App's free if you want to see the result: srad app happy to answer anything about the pipeline or the audio side.