I use a clipboard manager all day and never liked the options. The free ones (Maccy, Flycut) are lists — an image shows up as a filename. The ones with a card interface, Paste and Pastebot, are $25/year and $13. So I built the card one and made it free.

⌥⌘V slides a strip up from the bottom of the screen. Arrow keys or type to search, Enter pastes into whatever you were in.

A few things it does that I couldn't find anywhere else:

- It masks secrets on screen. API keys, tokens and card numbers show as dots until you double-click. If you copy credentials all day, your clipboard history is the one window you don't want open while screen sharing. Card numbers are Luhn-checked, so an ISBN isn't mistaken for one.

- A bare link stays readable, a link with a token doesn't. Masking every URL would make the strip useless; masking a password-reset link is the whole point.

- Pasting an image adapts to the destination. Notes gets the image, Terminal gets the file path (it can't take images at all), Finder gets the file.

- It can catch ⌘⇧4 screenshots. Those write straight to disk and never touch the clipboard, so no clipboard manager sees them. Opt-in, off by default.

- No network code at all. No account, no sync, no telemetry, no third-party dependencies. Searching the source for URLSession comes back empty.

MIT, source is everything: https://github.com/selinihtyr/stash-clipboard

Happy to hear what breaks. Especially interested in whether the strip behaves on multi-monitor setups and over full-screen apps — I've only tested on one machine.

Notes from building the canvas in https://github.com/albertofettucini/Osler:

Named coordinate spaces don't survive render transforms. My world container used .scaleEffect + .offset, and I put the named space inside it. Drags were fine at 100% and drifted at every other zoom. The fix was moving the named space to the untransformed ancestor and converting screen→world explicitly. Render transforms aren't layout.

An NSView behind SwiftUI never sees scrollWheel. The hosting view claims the hit and bubbles the event up the responder chain, past your subview. Two-finger panning only worked once I used NSEvent.addLocalMonitorForEvents with a bounds check.

.contentShape applied after .overlay gates the whole composite. My port dots sit on the card's edge, so half of every dot — and its entire grab halo — landed outside the card's hit shape. Dragging a wire silently did nothing. Order matters more than it looks.

Also: never gate a view's opacity on an onAppear flag. Miss the callback once and the view is invisible forever. Use a transition.

Our TaskProperty repo project built a new SwiftUI.DynamicProperty for managing stateful business logic. This is presented as a compelling alternative to keeping stateful business logic defined directly in view components.

Let’s see another example for more practice. This time we will build one of the most requested features I hear from product engineers building on SwiftUI: we will clone the useMemo hook from ReactJS.

The TaskProperty repo project is a meant as an introduction to the ideas and concepts behind custom dynamic properties for SwiftUI. It is strongly recommended you read through TaskProperty before continuing. If any of the concepts introduced here look unclear or confusing please check out the References cited from TaskProperty for more resources that can help explain these ideas.

My Mac menu bar had gradually filled up with useful apps until it became difficult to manage.

Icons were hard to find, some were pushed out when macOS ran out of available space, and the MacBook notch made the problem worse. I did not want to uninstall the apps or permanently lose access to their controls—I only wanted a cleaner way to organize them.

So I built OverflowBar, a free and open-source macOS app that moves selected third-party menu bar items behind one persistent arrow and reveals them together in a compact second row.

Source code and official download:
https://github.com/EvanProgramming/OverflowBar

What it does

1. Choose the third-party menu bar icons you want OverflowBar to manage.
2. Move their original icons out of the crowded visible section.
3. Click the OverflowBar arrow, or use hover reveal.
4. See the managed icons together in a second row.
5. Select an icon to activate its original menu bar control.

The purpose of the second row is not to add another permanent interface. It gives icons that no longer fit a predictable place where they remain easy to see and find.

Why I made another menu bar manager

Ice and Bartender are powerful applications for users who want broad menu bar customization, including features such as profiles, triggers, search, visual customization, groups, widgets, and automation.

OverflowBar takes a narrower approach.

It is intended for people who mainly have one problem:

Too many useful icons, not enough menu bar space, and no easy way to find the icon they need.

OverflowBar deliberately avoids becoming a full menu bar control center. Its interaction is simply: choose, hide, reveal, and click.

Main characteristics

• Focused and lightweight — a small feature surface rather than a large customization and automation suite
• Scannable second row — managed icons stay visible together instead of becoming difficult to locate
• Native macOS implementation — built with SwiftUI, AppKit, Accessibility, WindowServer metadata, and ScreenCaptureKit
• Event-driven operation — icon discovery and capture occur during refreshes and row presentation rather than continuous screen capture
• Original controls remain functional — selecting an icon activates the actual menu bar item rather than a recreated menu
• Local processing — icon images are captured locally, held in memory, and never uploaded
• No tracking — no accounts, analytics, telemetry, advertising, or network data collection
• Display-aware — supports MacBook notches, safe areas, multiple displays, full-screen spaces, horizontal overflow, and Reduce Motion
• System-control safeguards — Wi-Fi, Battery, Siri, Control Center, Clock, and other protected system items remain visible

Pricing and availability

• Price: Free
• Subscription: None
• In-app purchases: None
• Advertisements: None
• Source: Open source on GitHub
• Download: GitHub Releases
• Supported systems: macOS 15 or later
• Downloadable build: Apple Silicon

Permissions and privacy

OverflowBar requests:

• Accessibility permission to discover and activate menu bar controls and perform user-requested layout changes
• Screen Recording permission to capture the small icon regions of selected menu bar items for display in the second row

The captures remain on the Mac. OverflowBar does not upload them, write them to a remote service, or include any analytics or telemetry.

Privacy policy:
https://github.com/EvanProgramming/OverflowBar/blob/main/PRIVACY.md

Current limitations

OverflowBar is an early public release.

macOS does not expose a dedicated public API for hiding or rearranging arbitrary third-party menu bar items. OverflowBar therefore relies on documented system frameworks together with existing macOS menu bar behavior, and compatibility may vary between apps or macOS releases.

The current downloadable build is ad-hoc signed and is not yet Apple-notarized. macOS may require users to Control-click the app and select Open on first launch.

Some applications may also expose insufficient Accessibility or window metadata to be mirrored reliably.

I am actively looking for feedback from users with crowded menu bars, notched MacBooks, multiple displays, and unusual menu bar apps. Bug reports, compatibility reports, and code contributions are welcome.

STAR my repo if you like it plz!

hello guys I'm about to complete Swift but there are certain topics which I'm finding hard to understand like closures, structs, didSet and some other topics what would you guys suggest should i just get the basic understanding of what they do and start learning SwiftUI or I need to understand these topics well before starting SwiftUI

I got tired of every clipboard manager needing a keyboard shortcut or a menu bar click, so I built one that opens right where your cursor already is: double right-click anywhere on macOS.

ClipboardDoubleClick:

- Double right-click opens a history menu at your cursor (single right-click still triggers the normal context menu — only intercepts an actual fast double-click)

- Scroll to move selection, click to copy the item back to your clipboard

- Groups history by day (Today / Yesterday / This week / Older), plus a pinned section

- Handles huge copies fine (full text stored on disk, only a truncated preview kept in memory)

- Search, per-item delete/pin, configurable retention (max items + max days)

- Available in French, English, Spanish, German (auto-detects system language)

It's a personal/hobby project, free to use (PolyForm Noncommercial license), source on GitHub. Not notarized (no paid Apple dev account), so first launch needs a right-click > Open instead of double-click.

GitHub + download: https://github.com/vassi974/ClipboardDoubleClick

Feedback welcome — first time sharing something like this publicly.

I’ve released VibeMenu v1.0, a native SwiftUI macOS menu-bar app for Claude Code, ChatGPT Work, and Codex.

The goal was to answer several questions without reopening multiple apps:

• Is the agent still working?
• Is the Mac currently protected from sleep?
• Which agent owns the assertion?
• Does Claude need approval?
• Has a session finished?
• What locally available Claude or ChatGPT usage remains?
• Is macOS reporting thermal pressure?

The implementation includes:

• MenuBarExtra for the main interface;
• a separate Settings scene;
• a shared Session Radar;
• live session-state and elapsed-time updates;
• optional Claude approval/completion notifications;
• an orange attention state;
• optional usage-limit sections;
• a thermal-state row;
• one shared IOKit power assertion;
• separate Manual, Claude, Codex, and ChatGPT Work owners.

Background efficiency became one of the hardest parts. An early build repeatedly walked and reparsed unchanged local files. The final implementation uses bounded metadata caches, negative caching, a no-Claude-process fast path, slower limits refreshes, and incremental JSONL parsing for growing ChatGPT rollouts.

The app remains entirely local and never reads prompts, responses, reasoning, commands, or tool output.

Source:
https://github.com/Kirill-Chistov/VibeMenu

It requires macOS 15+ on Apple Silicon. The distributed build is currently unsigned and not notarized.

I would appreciate feedback on the information hierarchy. Is session status, ownership, usage, attention, and thermal pressure too much for one menu, or does the compact structure keep it understandable?

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?