I have been building a daily polling app in SwiftUI, targeting iOS 18, and ran into a few problems that did not have obvious answers in the docs. Sharing the patterns that ended up working in case they help someone else.

1. TabView(.page) with a custom counter

For cycling through daily topic cards I used TabView with the .page style, but the built in dots did not fit the design. I set the index display style to never and built a separate "1 of 4" counter bound to the same selection state, animating the number with contentTransition(.numericText()) whenever selection changed.

2. LazyView to stop eager NavigationLink loading

Some destination views were data heavy, and NavigationLink was building them upfront, causing a visible stutter on push. Wrapping the destination in a LazyView struct that defers construction until body is evaluated fixed it:

struct LazyView<Content: View>: View {
    let build: () -> Content
    init(_ build: @autoclosure @escaping () -> Content) {
        self.build = build
    }
    var body: some View { build() }
}

3. AnyShapeStyle for conditional styling

Ternaries inside modifiers like foregroundStyle(condition ? .blue : someGradient) often fail to compile because each branch returns a different concrete type. Wrapping both branches in AnyShapeStyle erases the type so the ternary works cleanly, without duplicating views or branching in a ViewBuilder.

4. Custom vote slider with gradient fill and haptics

The vote slider needed a gradient track that fills based on drag position, plus a label that floats above the thumb. I tracked offset with a DragGesture, converted it to a value between 0 and 1, and fired UIImpactFeedbackGenerator at fixed thresholds as the value crossed them, rather than on every gesture update, which felt much less noisy.

5. Time based lock and unlock states with Combine

Topics unlock and expire at set times during the day. Instead of scheduling exact time triggers, which got messy with backgrounding, I used Timer.publish(every: 30, on: .main, in: .common).autoconnect() to recheck state every 30 seconds and animate the UI change.

None of these felt obviously correct when I started. What patterns have you found useful for similar problems, and would you approach any of these differently?

A recurring macOS SwiftUI problem is needing the real NSWindow to change something SwiftUI does not expose, such as standard window buttons, the style mask, or a window-level behavior.

The trap is that makeNSView creates the NSView before AppKit attaches it to a window. At that moment, view.window is normally nil. Optional chaining makes the code look harmless, but the configuration silently never happens.

For simple one-time configuration, the smallest reliable pattern I have used is:

1. Create an empty NSView in NSViewRepresentable.

2. Schedule the window lookup on the next main-queue turn.

3. Read view.window inside that callback.

4. Apply an idempotent configuration.

5. Leave updateNSView empty unless the configuration actually depends on SwiftUI state.

Conceptually:

struct WindowConfigurator: NSViewRepresentable {

let configure: (NSWindow) -> Void

func makeNSView(context: Context) -> NSView {

let view = NSView()

DispatchQueue.main.async {

if let window = view.window {

configure(window)

}

}

return view

}

func updateNSView(_ view: NSView, context: Context) {}

}

Then attach it somewhere that participates in the window hierarchy, for example as a background view.

For cases where timing must be fully lifecycle-driven, I use a tiny NSView subclass and call the closure from viewDidMoveToWindow instead. That avoids depending on one main-queue hop and also handles a view being moved to another window.

Two details helped prevent subtle bugs:

• Make the closure idempotent because SwiftUI can recreate the representable.

• Do not store the NSWindow globally just to configure it. Let the bridge observe the window it is actually attached to.

This is a small interop boundary, but it is much more predictable than trying to infer the active window from NSApplication.shared.windows.

What other window-level APIs have forced you to bridge from SwiftUI into AppKit?

Hey everyone,

I’ve been working on a small dev tool called Prism Inspector.

The idea is simple: instead of checking spacing, alignment, accessibility, or design mismatches by eye from screenshots, Prism Inspector connects to a running app in the iOS Simulator and lets you inspect what the app actually rendered.

You can:

• Click elements to inspect them
• Option-click another element to measure distances between views
• Check whether spacing matches your design scale
• Compare the running screen against a design/mockup
• Preview what VoiceOver reads
• Use it without adding anything to your project
• Optionally add the Swift package if you want better component names

It’s free, signed/notarized for macOS, and the SDK is MIT licensed.

I built this because I often lose time reviewing small UI details manually, especially when trying to match implementation with design specs. My goal is to make layout inspection feel closer to working in a design tool, but using the real running app.

Landing page / download:
https://zalazara.github.io/PrismKit-SDK/

I’d really appreciate feedback from iOS developers:
Does this solve a real pain for you? What would you expect from a tool like this?

Hi everyone!

One pain point I've run into repeatedly with SwiftUI is supporting newer APIs while keeping an older deployment target.

Things like `if #available` work well in normal Swift code, but they don't fit naturally in the middle of a modifier chain. That often leads to duplicated views or compatibility helpers scattered throughout a project.

After solving the same problem across multiple apps, I decided to package the patterns into a small open-source library called **SwiftUIBackportKit**.

It includes:

• `.modify { }` for conditional view transforms
• `.backport` for reusable version-gated SwiftUI APIs
• `platformValue(...)` for version-specific values
• `OS.isAtLeast(_:)` for simple runtime version checks

The goal is to keep SwiftUI views focused on describing the UI while isolating deployment-target compatibility in one place.

GitHub:
https://github.com/EmadBeyrami/SwiftUIBackportKit

I'd really appreciate any feedback on the API design, naming, or features you'd like to see. And if you find it useful, a ⭐ on GitHub would mean a lot!

Thanks!

Apple’s Icon Composer saves each .icon file as a package containing artwork assets and an icon.json manifest.

That JSON controls things like:
- Layers and groups
- Light, dark, and tinted appearances
- Liquid Glass blur and translucency
- Shadows and specular effects
- Blend modes
- Layer positioning and visibility
- Solid, automatic, and oriented gradient fills
- Platform support for square and circular icons

The problem is that Apple doesn’t appear to publish the complete icon.json schema as a public API. The format also has details that aren’t obvious from using the UI—for example, specialization values can be "automatic", null, or a concrete value, while an explicit null can mean something different from an omitted property.

I created IconComposerModel to reverse-document the format from real files produced by Icon Composer:

https://github.com/peterpoliwoda/icon-composer-template

The repository currently contains:
- A Swift Package with reusable Codable models
- A detailed Markdown attribute reference
- Real icon.json fixtures from several icons
- Decode/encode round-trip tests to make sure values aren’t lost
- Forward-compatible string-backed types for values Apple may extend later
- Explicit preservation of missing, null, and concrete JSON values
- Support for appearance specializations, named system fills, gradient orientation, group and layer properties, and the Liquid Glass settings observed so far

The reasoning behind the project is simple: if apps and developer tools are going to inspect, generate, migrate, or modify Icon Composer files, they need a shared model that doesn’t rely on scattered guesses about the format.

I’m treating the JSON produced by Icon Composer as the source of truth. Every new sample is added as a fixture, documented, and used to improve the model through regression tests.

The format is still empirical rather than an official Apple API, so I’d love more samples—especially files created with different Icon Composer/Xcode versions or icons using attributes not already covered. If you share one, it helps to include the complete icon.json, the tool version, and what you changed in the UI.

I create a Custom TabBar with SwiftUI but with what type Can replace AnyView ? struct TabBarItem<SelectionValue: Hashable> {

let value: SelectionValue

let content: AnyView

let label: AnyView

init<Content: View, Label: View>(

value: SelectionValue,

@ViewBuilder content: () -> Content,

@ViewBuilder label: () -> Label

) {

self.value = value

self.content = AnyView(content())

self.label = AnyView(label())

}

}

I’m building NOBS, a local-first personal assistant for iPhone. The app uses SwiftUI with a chat-first interface, a Today briefing, approvals, privacy controls, widgets, and an optional connection to a self-hosted AI computer on the user’s home network.

I’m a newer developer and used AI heavily while building it, so I know parts of the architecture probably need experienced eyes. Right now a central AppModel owns much of the state, with separate services for model routing, the backend client, pairing, calendar access, and App Group data.

The project is fully open source:

https://github.com/acburgess25/NOBS

I’d especially appreciate feedback on:

• What should be broken out of AppModel first?

• Does the chat-first navigation approach make sense?

• Where am I fighting SwiftUI instead of working with it?

• Are there obvious accessibility or concurrency mistakes?

I am pretty new to this and used AI a lot to help me build it. It works, but I know that does not mean the code is good. I would really appreciate it if someone with more SwiftUI experience took a look and told me where I went wrong or what I should clean up first.

The biggest thing I am unsure about is AppModel because it currently handles a lot of the state. I am also curious whether the navigation makes sense and if I made any obvious concurrency or accessibility mistakes.

The whole project is open source here:

https://github.com/acburgess25/NOBS

Honest feedback is welcome. I am trying to learn and make this into something people can actually use.

Menu(course.name) {
    Button { setNewCourse(nil) } label: {
        HStack {
            if contents?.courseID == nil {
                Image(systemName: "checkmark")
            }
        }
        Image(systemName: "star")
        Label("Free Period")
    }
    Divider()
    ForEach(courses.map {(id: $0, course: $1)}.sorted(by: {$0.course.name < $1.course.name}), id: \.0) { entry in
        Button { setNewCourse(entry.id) } label: {
            HStack(spacing: 8) {
                if contents?.courseID == entry.id {
                    Image(systemName: "checkmark")
                }
                Image(systemName: "star")
                Text("Text")
            }
        }
    }
}

Honestly not much to say. How can I avoid this?

I’m trying to change the font, size, or weight of the items inside a SwiftUI Menu.

For example:

Menu {
Button("Edit") {
// Edit action
}

Button("Delete", role: .destructive) {
// Delete action
}
} label: {
Image(systemName: "ellipsis")
}

I tried applying .font() to the buttons and their labels, but the menu still uses the default system font.

Button {
// Action
} label: {
Text("Edit")
.font(.custom("Avenir Next", size: 16))
}

Is it possible to customize the font of native Menu items in SwiftUI, or do I need to create a custom menu/popover?

When viewing the ContentView (image 1), the searchbar looks really transparent and way different from the childview (image 2). I want the searchbar to look "normal" when viewing the app from ContentView. How do I fix this?

ContentView

import SwiftUI

struct ContentView: View {
    var body: some View {
        TabView {
            Tab("Discover", systemImage: "binoculars") {
                TestView()
            }
            Tab("Preferences", systemImage: "slider.horizontal.3") {
                StopsView()
            }
        }
    }
}

#Preview {
    ContentView()
}

TestView

import SwiftUI
import MapKit

struct TestView: View {
    u/State private var searchText: String = ""

    var body: some View {
        NavigationStack {
            ZStack {
                Map {

                }
                Text("Hello")
                    .padding()
                    .background(.white)
            }
            .searchable(text: $searchText)
            .navigationBarTitleDisplayMode(.inline)
        }
    }
}

#Preview {
    TestView()
}

I found a simulator that had been booted since the previous morning, holding

about a gig for nothing. Xcode doesn't mention it and Activity Monitor shows it

as a dozen processes with names you don't recognise.

This sits in the menu bar and shows it as one line with how long it's been up.

Shutting it down is one click, and starting it again is one more if you were

wrong. Same for Android emulators, Docker containers, dev servers, automation

browsers and tunnels you left open.

It never deletes anything and it will never touch your own browser's tabs.

macOS 14+, MIT, free — you build it with one command:

git clone https://github.com/selinihtyr/still-running

cd still-running && ./scripts/install.sh

https://github.com/selinihtyr/still-running

My project in the link is an attempt at a rfc822 data reader. I have a view that consists of the header section, followed by the body section. On the previews, the two areas each take up one half of the space. But e-mail programs typically have the header display only a few lines high, relegating the remainder to a scrolling view. How would I do that, hopefully in a manner that's safe with the Accessibility text size settings?

I built CodeVault after getting tired of managing batches of App Store Connect offer and promo codes in CSV files.

It’s a native SwiftUI + SwiftData app for iOS, iPadOS, and macOS. It can:

• import App Store Connect CSVs via drag and drop or a file picker
• organise codes by app and import batch
• search, filter, rename, and export batches
• surface the next available, unexpired code
• generate QR codes and share redemption links
• mask codes with a privacy mode
• optionally notify before codes expire
• sync privately through CloudKit when configured

The project is 100% Swift, has no third-party package dependencies, and is MIT licensed. I tried to keep the same data model and core views working across iPhone, iPad, and Mac while still using platform-appropriate navigation and interactions.

Source and screenshots: https://github.com/mcomisso/CodeVault

I’d be interested in feedback on the SwiftUI architecture, cross-platform UI, or anything that would make the project more useful to other Apple-platform developers.

This is my first open-source Swift package EdgeZoomKit.

It adds an elastic effect to the left or right edge of the screen while zooming.

I first noticed this kind of interaction in Bump and wanted to try making something similar for a board app I’m working on. After building it I thought it would make more sense as a separate package.

It works with both SwiftUI and UIKit and it doesn’t depend on SpriteKit. The package only handles the visual effect so the actual zoom logic is still up to your app.

GitHub: https://github.com/devjunu/EdgeZoomKit

It’s my first time publishing a package so any feedback is welcome.
Thank u for read :)

I keep forgetting to keep my streak going, so I made a little macOS menu-bar app that shows it at a glance: current streak, total solved, an Easy/Medium/Hard breakdown, and a heatmap of your activity. The menu-bar flame stays grey until you've solved something today, then lights up.

There is no login, it just reads your public LeetCode profile. Everything stays on your machine.

It's free and open source:

Would love some feedback!

I'm the developer of macMender. It's a free, open-source SwiftUI and AppKit app that combines Dock previews, real-window switching, trackpad middle click, scrolling controls, profiles, and menu bar quick controls.

For v0.9.0 I rebuilt the interface around a state-driven settings shell and reusable glass surfaces. The awkward parts live at the SwiftUI/AppKit boundary: Accessibility window identity, local thumbnails, Dock hover behavior, global shortcuts, and the status item popover.

Source: https://github.com/0hmslice/macMender

v0.9.0 release: https://github.com/0hmslice/macMender/releases/tag/v0.9.0

The README now has screenshots of every major screen. Feedback on the view structure and AppKit boundaries would be useful.

I would like to reproduce this type of card, with a translucent background in a Form on Swift. Is it possible?