Forem: Im Woojin

DualClip v1.2.6 — Stability Fix, Homebrew

Im Woojin — Tue, 14 Apr 2026 07:57:34 +0000

It's been a busy couple of days for DualClip. What started as a frustrating crash investigation turned into a series of meaningful improvements — from fixing a deep resource-bundling bug to shipping Homebrew support. Here's a rundown of everything that changed.

The Crash That Wouldn't Quit

Shortly after v1.2.0, DualClip started crashing on launch for some users. The crash report pointed to Bundle.module inside the KeyboardShortcuts dependency — a fatalError triggered because the app couldn't locate its resource bundle at runtime.

The root cause turned out to be a subtle mismatch in how Swift Package Manager bundles resources for standalone .app builds:

SPM generates a file called resource_bundle_accessor.swift that looks for resources at Bundle.main.bundleURL — which resolves to the .app/ root directory.
But macOS codesigning requires all resources to live inside Contents/Resources/, not the app root. Placing bundles at the root causes an "unsealed contents" signing error.
So the resources were in Contents/Resources/, but the code was looking at .app/ — and finding nothing. The fix was surgical: after the initial build, we patch the generated accessor to use Bundle.main.resourceURL! (which points to Contents/Resources/), then recompile just the affected module and re-link the executable. SPM regenerates the accessor on every full build, so we had to carefully avoid triggering a rebuild after patching. The final binary is verified with strings to confirm the patch is baked in.

This fix ships in v1.2.6 and the crash is fully resolved.

Homebrew Support

DualClip is now installable via Homebrew:

brew install RAKKUNN/tap/dualclip

We set up a dedicated Homebrew Tap with a Cask formula that points to the latest signed and notarized release. The CI pipeline automatically updates the formula (version + SHA256) whenever a new release is tagged — zero manual steps.

What Makes DualClip Different

After analyzing 57 macOS clipboard managers, one thing stood out: every single one is a clipboard history manager. DualClip is the only one that uses dedicated slots.

The difference matters:

History managers record everything you copy and let you scroll back through it. Great for recall, but adds complexity — databases, search UI, sync, storage limits.
DualClip gives you 3 fixed slots with instant keyboard access. You decide where to copy, not when to find it later. No history, no scrolling, no search.
It's also one of the few clipboard tools that stores absolutely nothing to disk. Everything lives in RAM and vanishes on quit. No network access, no telemetry, no cloud sync.

Try It

brew install RAKKUNN/tap/dualclip
Or grab the latest release from GitHub.

RAKKUNN / DualClip

A lightweight macOS app for multi-slot clipboard management

DualClip

A lightweight macOS menu bar app that provides multi-slot clipboard management.
Unlike history-based clipboard managers, DualClip gives you instant access to dedicated clipboard slots via customizable keyboard shortcuts

Features

3 Clipboard Slots: Slot A (system default), Slot B, and Slot C
Customizable Shortcuts: No hardcoded key conflicts — configure your own shortcuts
Atomic Paste: Seamlessly pastes from any slot without corrupting your system clipboard
Menu Bar Popover: Quick-glance view of all slot contents with previews
Privacy First: All data lives in RAM only — nothing is persisted to disk
Zero Network Access: No telemetry, no analytics, no internet communication

Demo

Default Shortcuts

Action	Shortcut
Copy to Slot B	⌥⌘C
Paste from Slot B	⌥⌘V
Copy to Slot C	⌃⌘C
Paste from Slot C	⌃⌘V

All shortcuts are fully customizable in Settings > Shortcuts.

How It Works

Slot A automatically mirrors the…

View on GitHub

Signed and notarized by Apple — no Gatekeeper warnings.

DualClip is open source under the MIT license. Issues, feedback, and contributions are welcome.

Thank you, have a nice day!

DualClip - Update_2026.04.12.

Im Woojin — Sun, 12 Apr 2026 07:48:23 +0000

Last week, I shared the first round of updates for DualClip, my open-source macOS clipboard manager. Since then, I’ve crossed off three major items from the roadmap—including the one I’m most excited about: you can finally download DualClip without needing to build it from source.

Here is the breakdown of what’s new in v1.1.0.

🔒 Secure Input Field Detection

This was at the top of my "What’s Next" list for a reason: Privacy.

When macOS has a password field focused, the system activates a mode called Secure Event Input. DualClip now checks for this state before every copy and paste operation. If you're typing a password into Safari, 1Password, or a terminal sudo prompt, DualClip silently steps back.

Swift
func isSecureInputActive() -> Bool {
    return IsSecureEventInputEnabled()
}

The guard is dead simple—one line in handleCopy and one in handlePaste:

Swift
guard !AccessibilityService.shared.isSecureInputActive() else { return }

It’s the kind of feature that, when it works correctly, you never notice. And that’s exactly the point.

📦 Prebuilt Binaries (No Xcode Required!)

The biggest friction point in my original post was: "There's no prebuilt binary yet." Starting with v1.1.0, every release is signed with a Developer ID certificate and notarized by Apple. This means:

No more Gatekeeper warnings.
No "Open Anyway" dance in System Settings.
Just download, drag to Applications, and go.

🏗 The CI/CD Saga: 3 Bugs and a Notarization Pipeline

Getting the automated release pipeline working was... an adventure. I’m using GitHub Actions to handle the heavy lifting. The workflow triggers on version tags (v*..) and follows this sequence:

Build: swift build -c release on a macOS 14 ARM runner.
Import: Decode the .p12 certificate from GitHub Secrets.
Bundle: Assemble the .app structure.
Sign: codesign with hardened runtime and a timestamp.
Notarize: Submit to Apple, poll for completion, and staple the ticket.

Sounds clean on paper. In practice, it took four attempts and taught me three very humbling lessons:

Bug 1: The One-Character Typo
I spent 10 minutes staring at a 401 Unauthorized error from Apple’s API. It turned out to be a typo in my app-specific password secret: fjhk vs tihk. CI/CD reminds you that your eyes see what they want to see, not what’s actually there.

Bug 2: The Service Outage
Three consecutive submissions got stuck at "In Progress" for hours. I thought my script was hung. It turns out Apple's notarization service was actually having a global outage. Even the best pipeline can’t fix a broken cloud.

Bug 3: The awk Failure
My polling script used awk '{print $2}' to extract the status from notarytool info. However, the status string for a pending job is In Progress (two words). awk captured only "In," which matched nothing in my logic.
The Fix: Switched to sed 's/.*status: //' to grab the full string.

🔄 Updated Roadmap

Feature Status
Secure input field detection ✅ Shipped
RAM zeroing on termination ✅ Shipped
Image/rich text support ✅ Shipped
GitHub Actions CI/CD + Notarization ✅ Shipped
Homebrew Cask distribution 🔜 Next
Sparkle auto-update 📅 Planned

Try it out

If you’ve been waiting for a downloadable build, it’s ready for you:

Go to the Latest Releases.
Download DualClip-1.1.0-arm64.zip.
Unzip, move to Applications, and launch.
Grant Accessibility permission when prompted.

🔗 GitHub: https://github.com/RAKKUNN/DualClip

If you find a bug or have a feature request, feel free to open an issue or a PR!

DualClip - Update_2026.04.04.

Im Woojin — Sat, 04 Apr 2026 10:54:46 +0000

DualClip Update — Beyond Text, and a 150ms Correction

A few hours ago, I shared DualClip, a slot-based clipboard manager for macOS. Thank you to everyone who checked it out!

Since then, I've shipped a few meaningful updates that I didn't cover in the original post. I also owe you a small correction. Let me walk through both.

🔧 First, a correction: 50ms → 150ms

In my first post, I wrote that the Atomic Paste operation completes "in less than 50ms." That was wrong. The actual restore delay is 150ms.

/// 150ms is an empirically safe value to prevent race conditions.
private let restoreDelayMs: Int = 150

150ms was chosen empirically to avoid a race condition — if the clipboard is restored before the target application finishes reading it, the paste silently fails. 50ms sounded cooler, but 150ms is what actually works reliably. Sorry about that.

⚡ How Atomic Paste actually works

Since this is the core mechanic of DualClip, I figured it deserves a proper breakdown. When you press the hotkey to paste from Slot B, here's what happens under the hood:

1. Backup — The entire system clipboard (Slot A) is deep-copied into a temporary buffer. Not just text — all NSPasteboardItem types and their raw data.

2. Swap — Slot B's content is written to the system clipboard, replacing whatever was there.

3. Simulate — A CGEvent-based ⌘V keystroke is posted to the HID system. This is why DualClip requires Accessibility permission — it's literally pressing keys on your behalf.

4. Restore — After 150ms, the backup is written back to the system clipboard. Your original ⌘C content is untouched.

The entire flow is invisible to the user. You press a hotkey, text appears, and your clipboard stays exactly as it was.

🖼 Multi-content type support

The first post only showed text workflows, which gave the impression that DualClip is text-only. It's not — it now supports four content types:

Type	Example
Plain text	Code snippets, URLs, API keys
Rich text (RTF)	Formatted text with bold, colors, etc.
Images	Screenshots, design assets from Figma
File URLs	File paths copied from Finder

Each slot stores the raw NSPasteboardItem data faithfully, so what you copy is exactly what you get back — formatting, metadata, and all.

This means you can now keep a screenshot in Slot B and a HEX code in Slot C, then paste them alternately into your editor without touching the mouse.

🔐 RAM Zeroing on termination

In the first post, I mentioned that all data lives in RAM only. That's still true, but I've taken it a step further.

When DualClip quits, it doesn't just release memory — it overwrites every byte with zeros before deallocation:

func secureWipe() {
    if let items = pasteboardItems {
        for item in items {
            for type in item.types {
                if let data = item.data(forType: type) {
                    data.withUnsafeBytes { rawBuffer in
                        guard let baseAddress = rawBuffer.baseAddress else { return }
                        let mutable = UnsafeMutableRawPointer(mutating: baseAddress)
                        memset(mutable, 0, rawBuffer.count)
                    }
                }
            }
        }
    }
    clear()
}

This is called on applicationWillTerminate for all three slots. If you temporarily stored an API key or password in a slot, it won't linger in physical memory after the app closes.

To summarize the privacy model:

No disk writes. Nothing is persisted.
No network. Zero external communication.
RAM zeroing. Memory is scrubbed on exit.
Open source. You can verify all of the above yourself.

🏗 CI pipeline

I've added a GitHub Actions workflow that runs on every push and PR to main. It builds the project in both Debug and Release configurations on macOS 14 with Swift 5.9.

It's a simple setup — no notarization or automatic releases yet — but it catches build regressions before they land.

🛠 Building from source

There's no prebuilt binary yet, but building is straightforward if you have Xcode:

git clone https://github.com/RAKKUNN/DualClip.git
cd DualClip
open Package.swift

Hit ▶ Run in Xcode. On first launch, macOS will ask for Accessibility permission — this is required for the CGEvent keystroke simulation that powers Atomic Paste.

What's next

Secure input field detection (auto-disable in password fields)
Homebrew Cask distribution
Sparkle auto-update

This is still a small, single-purpose tool, but I'm trying to get the details right. If you have feedback or want to contribute, the repo is open.

🔗 GitHub: https://github.com/RAKKUNN/DualClip

Thanks for reading!

DualClip: multi-slot clipboard manager for macOS

Im Woojin — Fri, 03 Apr 2026 23:09:10 +0000

First project with macOS & Swift

I wanted to share DualClip, a native macOS menu bar app I’ve been working on.

While there are many great clipboard managers like Maccy or Paste, I found that most of them focus on "History"—searching through a vertical list of everything you've copied.

I built DualClip because I needed something that works more like a "Workbench." Instead of picking from a menu, DualClip gives you dedicated slots (A, B, and C) that you can access instantly via global hotkeys.

🚀 How it differs from history-based managers:

No List Selection: You don't have to break your flow to search or click an item from a list. You use ⌥⌘C to save to Slot B and ⌥⌘V to paste it instantly.

Atomic Paste: When you trigger a secondary slot, the app performs a high-speed "injection"—swapping the system clipboard, pasting, and restoring the original content in less than 50ms.

Parallel Workflow: Perfect for developers moving IDs and Emails simultaneously, or translators working with source and target text in two separate slots.

🔐 Privacy:

As a security enthusiast, I designed this with transparency in mind:

In-Memory Only: Clipboard data is stored strictly in RAM and is never written to disk.

Zero Network Access: The app has no network permissions. No telemetry, no analytics, no external communication.

🛠 Tech Stack:

Language: Swift 5.9+ / SwiftUI & AppKit Hybrid

The project is licensed under MIT, and I’d love to get some feedback or contributions from this community!

Thank you for reading my small project!

🔗 GitHub Repository: https://github.com/RAKKUNN/DualClip