pyrx.tech

Posted on May 22

I built a 12 MB native Mac app with zero third-party dependencies. Here's what I learned.

#swift #swiftui #buildinpublic

I spent the last several months building a macOS utility app in SwiftUI. The final binary is 12 MB with dependencies: [] in Package.swift — literally zero third-party packages.

This isn't a brag post. It's a collection of things that surprised me, tripped me up, or made me rethink how I approach macOS development. If you're building (or thinking about building) a native Mac app, hopefully some of this saves you time.

Why zero dependencies?

It wasn't an ideology thing at first. I just started building and never hit a point where I needed an external package badly enough to add one.

Networking? URLSession with async/await covers everything I needed (auth, license validation, update checks). No Alamofire.
JSON? Codable is built in. I haven't needed a custom JSON library since Swift 4.
Keychain? The Security framework API is ugly, but wrapping SecItemAdd / SecItemCopyMatching in a 50-line helper is less work than adopting a dependency.
Analytics? I commented out Firebase entirely. Crash logs write to ~/Library/Logs/ locally. I'll add opt-in analytics later if I need it, but for launch, local-only felt right.
UI? SwiftUI. No third-party component libraries.

The result: my Package.swift looks like this:

let package = Package(
    name: "CleanSlateX",
    // ...
    dependencies: [],
    // ...
)

And the app builds in under 30 seconds on an M-series Mac.

The tradeoff nobody talks about

Zero deps means you own every bug. When my Keychain wrapper silently failed on unsigned debug builds, there was no GitHub issue to search. I had to figure out that SecItemAdd returns -34018 when the app isn't code-signed, and build a fallback to AES-GCM encrypted file storage.

Would a Keychain library have handled that? Probably. But I would've spent the same time debugging their abstraction instead of Apple's API. Pick your poison.

SwiftUI for a utility app: the honest review

What worked great

Declarative UI for data-heavy views. My app shows long lists of files with sizes, checkboxes, and categories. SwiftUI's List + ForEach + @Observable made this almost trivial.
Dark mode and accessibility for free. Zero custom theming code. It just works.
Small binary size. SwiftUI links against system frameworks, so the app stays tiny.

What hurt

Previews are unreliable. They crash, they show stale data, they randomly stop updating. I switched to a live development workflow (build and run) for anything beyond trivial views. I know this defeats the purpose.
NSOpenPanel and AppKit interop. macOS SwiftUI still can't do everything. I needed NSOpenPanel for folder selection, SMJobBless for the privileged helper, and NSWorkspace for various system interactions. Wrapping AppKit in SwiftUI is doable but feels like duct tape.
Swift Concurrency + @MainActor propagation. Once you mark one view model as @MainActor, the annotation spreads through your codebase like a virus. Not necessarily bad, but surprising if you're used to GCD.

The privileged helper rabbit hole

My app needs to clean system-level caches (/Library/Caches/, /Library/Logs/), which requires root access. On macOS, the approved way to do this is SMJobBless — you create a separate helper binary that gets installed to /Library/PrivilegedHelperTools/ with a launchd plist.

What the docs don't tell you:

The helper and the app must reference each other's code signing requirements. The app's Info.plist lists the helper, the helper's Info.plist lists the app. Miss one and installation silently fails.
The helper validates its caller. Every XPC call, the helper checks SecCodeCheckValidity against the calling app's code signing identity. This prevents other apps from talking to your helper.
You need a command allowlist. The helper runs as root. If it can execute arbitrary shell commands, you've built a privilege escalation vulnerability. I hardcoded an allowlist of specific system utilities (tmutil, mdutil, dscacheutil, etc.) and scoped rm -rf to specific directory prefixes.
The user sees exactly one password prompt. AuthorizationCreate with kAuthorizationFlagInteractionAllowed shows the standard macOS admin dialog. After that, the helper stays installed and subsequent operations don't re-prompt.

This took me longer to get right than any other feature. If you're building a macOS utility that needs elevated permissions, budget a full week for this.

Notarization: the tax you have to pay

Apple requires Developer ID apps to be notarized — essentially, you upload your signed binary to Apple, they scan it, and staple a ticket that tells Gatekeeper "this is safe."

My pipeline:

# Build with Hardened Runtime + timestamp
xcodebuild ... CODE_SIGN_IDENTITY="Developer ID Application" \
  OTHER_CODE_SIGN_FLAGS="--timestamp --options runtime"

# Submit to Apple
xcrun notarytool submit CleanSlateX.dmg --wait --apple-id ... --team-id ...

# Staple the ticket
xcrun stapler staple CleanSlateX.app
xcrun stapler staple CleanSlateX.dmg

# Verify
spctl -a -vvv CleanSlateX.app

The gotcha: notarization fails silently if you forget --timestamp in the code signing flags. The binary looks signed, passes local verification, but Apple rejects it. This cost me half a day.

What I'd do differently

Start with the privileged helper on day one. I bolted it on later and had to refactor the entire cleanup pipeline. Design for split-process architecture from the start if your app needs it.
Don't fight Previews. Set up a lightweight preview-friendly architecture early (injectable mock data, protocol-backed services), or just accept that you'll use live builds.
Invest in a proper build script early. Code signing, notarization, DMG creation, version bumping — automate all of it. I have a single build-release.sh that does everything now, and it's the best time investment I made.
Ship the free tier first. I spent too long on the payment integration before validating that people wanted the core product. The free scan-only tier taught me more about user behavior in one week than months of building.

What's next

I'm launching on Show HN this Sunday. Honestly, I have no idea how it'll go — the "Mac cleaner" category has a lot of baggage on HN. But the app is built for developers specifically (13 dev toolchains, per-item transparency), and I think the engineering-first approach will resonate with that audience. Or they'll tell me rm -rf is all anyone needs. Either way, I'll learn something.

If you made it this far — what's your experience been with native macOS development? Are you still fighting AppKit, or has SwiftUI gotten good enough for your use case? I'd genuinely love to hear.

I'm building CleanSlateX, a macOS utility that audits and cleans developer tool caches. You can check it out at cleanslatex.app — the scan is free, no account required.

DEV Community