Forem: pyrx.tech

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

pyrx.tech — Fri, 22 May 2026 04:54:26 +0000

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.

The Complete Xcode Cleanup Guide for iOS/macOS Developers — Reclaim 50-150 GB (2026)

pyrx.tech — Tue, 19 May 2026 12:46:40 +0000

If you've been doing iOS/macOS development for more than a year, Xcode has been quietly claiming 50-150 GB of your disk without telling you. Here's where all that space went and exactly how to get it back.

I'll cover every major Xcode storage sink — DerivedData, simulators, device support, archives, SPM cache, and module cache — with the exact commands to audit and clean each one. Everything here is safe and reversible.

The quick audit: see your damage in 10 seconds

Run this first to understand the scale:

echo "=== Xcode Storage Audit ===" && \
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null && \
du -sh ~/Library/Developer/CoreSimulator 2>/dev/null && \
du -sh /Library/Developer/CoreSimulator/Images 2>/dev/null && \
du -sh ~/Library/Developer/Xcode/Archives 2>/dev/null && \
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport 2>/dev/null && \
du -sh ~/Library/Developer/Xcode/watchOS\ DeviceSupport 2>/dev/null && \
du -sh ~/Library/Developer/Xcode/tvOS\ DeviceSupport 2>/dev/null && \
du -sh ~/Library/Caches/org.swift.swiftpm 2>/dev/null && \
du -sh ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex 2>/dev/null

On my machine after 18 months of active development, the total was over 90 GB. Here's what each one is and what to do about it.

1. DerivedData (typically 20-60 GB)

What it is: Xcode's intermediate build output — compiled objects, indexes, build logs, module caches. Every project gets its own subfolder.

Location: ~/Library/Developer/Xcode/DerivedData/

Is it safe to delete? Yes. Xcode regenerates everything on the next build. The only cost is a full rebuild instead of an incremental one. Your source code, provisioning profiles, and App Store submissions are not affected.

How to clean it

Option A — Delete everything:

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Option B — Delete selectively (keep active projects):

# See each project folder with size and last modified date
ls -lahSt ~/Library/Developer/Xcode/DerivedData/

# Delete only folders older than 30 days
find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mtime +30 -exec rm -rf {} +

Option C — From Xcode UI:
Xcode → Settings → Locations → click the arrow next to "Derived Data" to open in Finder. Delete what you don't need.

Pro tip: Cmd+Shift+K in Xcode only cleans the current project's build folder. It doesn't touch other projects' DerivedData.

2. Simulator runtimes (5-8 GB each)

What it is: Full OS images for every iOS/watchOS/tvOS version you've ever downloaded. Each one is 5-8 GB.

Where they live:

User runtimes: ~/Library/Developer/CoreSimulator/Profiles/Runtimes/
System images (Xcode 15+): /Library/Developer/CoreSimulator/Images/

How to clean them

# List all installed runtimes with sizes
xcrun simctl runtime list

# Preview what would be deleted (dry run — deletes nothing)
xcrun simctl runtime delete --notUsedSinceDays 180 --dry-run

# Actually delete runtimes not used in 6 months
xcrun simctl runtime delete --notUsedSinceDays 180

# Nuclear option: delete all unavailable/orphaned simulators
xcrun simctl delete unavailable

Or via Xcode: Settings → Platforms → click the minus button on runtimes you don't need.

Rule of thumb: Keep only the 2-3 most recent iOS versions you actively test against. You can always re-download a runtime if you need it.

3. Device support files (1-5 GB per iOS version)

What it is: Debug symbols generated every time you plug in a physical device running a specific iOS version. These accumulate for every iOS version you've ever connected.

Location: ~/Library/Developer/Xcode/iOS DeviceSupport/

How to clean them

# See all device support folders with sizes
du -sh ~/Library/Developer/Xcode/iOS\ DeviceSupport/* | sort -hr

# Delete support files for iOS versions you no longer target
# Example: delete everything older than iOS 17
ls ~/Library/Developer/Xcode/iOS\ DeviceSupport/ | while read d; do
  version=$(echo "$d" | grep -oE '^[0-9]+')
  if [ "$version" -lt 17 ] 2>/dev/null; then
    echo "Removing: $d"
    rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/"$d"
  fi
done

Also check watchOS DeviceSupport and tvOS DeviceSupport if you've ever connected an Apple Watch or Apple TV.

4. Xcode archives (2-10 GB per archive)

What it is: .xcarchive bundles from every App Store submission or export you've ever done.

Location: ~/Library/Developer/Xcode/Archives/

How to clean them

From Xcode: Window → Organizer → Archives tab → right-click old archives → Delete.

From Terminal:

# See archive sizes grouped by year
du -sh ~/Library/Developer/Xcode/Archives/*

# Delete archives older than 1 year
find ~/Library/Developer/Xcode/Archives -maxdepth 1 -mtime +365 -exec rm -rf {} +

Keep in mind: You only need archives if you want to upload a build to App Store Connect, generate dSYMs, or re-export an IPA. If the app version is already live and you have dSYMs uploaded, the archive is safe to delete.

5. SPM cache (3-8 GB)

This one is sneaky — Swift Package Manager stores resolved packages in a cache directory that grows silently.

Location: ~/Library/Caches/org.swift.swiftpm/

How to clean it

# Check size
du -sh ~/Library/Caches/org.swift.swiftpm/

# Delete the global cache
rm -rf ~/Library/Caches/org.swift.swiftpm/

# Per-project cleanup
swift package purge-cache
swift package reset

The stale references gotcha: Xcode sometimes caches resolved package versions in DerivedData even after you've updated dependencies. If you see version mismatch issues after updating a package:

Close Xcode completely
Delete ~/Library/Caches/org.swift.swiftpm/
Delete the project's DerivedData folder
Delete Package.resolved from your project
Reopen Xcode and let it re-resolve from scratch

Unlike Cargo (cargo cache --autoclean-expensive) or pip (pip cache purge), SPM has no built-in cache size management. It's a genuine gap in the tooling.

6. Module cache

What it is: Precompiled module files shared across all Xcode builds.

Location: ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/

# Check size
du -sh ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/

# Delete it (regenerated automatically)
rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/

This is typically 1-3 GB and gets regenerated on the next build. Safe to delete anytime.

The complete cleanup script

Here's a single script that audits everything, shows you the totals, and lets you decide what to remove:

#!/bin/bash
echo "=== Xcode Disk Space Audit ==="
echo ""

paths=(
  "$HOME/Library/Developer/Xcode/DerivedData"
  "$HOME/Library/Developer/CoreSimulator"
  "/Library/Developer/CoreSimulator/Images"
  "$HOME/Library/Developer/Xcode/Archives"
  "$HOME/Library/Developer/Xcode/iOS DeviceSupport"
  "$HOME/Library/Developer/Xcode/watchOS DeviceSupport"
  "$HOME/Library/Developer/Xcode/tvOS DeviceSupport"
  "$HOME/Library/Caches/org.swift.swiftpm"
  "$HOME/Library/Developer/Xcode/DerivedData/ModuleCache.noindex"
)

total=0
for p in "${paths[@]}"; do
  if [ -d "$p" ]; then
    size=$(du -sm "$p" 2>/dev/null | cut -f1)
    total=$((total + size))
    printf "%6s MB  %s\n" "$size" "$p"
  fi
done

echo ""
echo "Total: $((total / 1024)) GB reclaimable"
echo ""
echo "To clean DerivedData:    rm -rf ~/Library/Developer/Xcode/DerivedData/*"
echo "To clean simulators:     xcrun simctl runtime delete --notUsedSinceDays 180"
echo "To clean SPM cache:      rm -rf ~/Library/Caches/org.swift.swiftpm/"
echo "To clean module cache:   rm -rf ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/"
echo "To clean archives:       Open Xcode > Window > Organizer > delete old archives"
echo "To clean device support: Manually delete old iOS versions from ~/Library/Developer/Xcode/iOS DeviceSupport/"

Preventing future bloat

After every major Xcode update: review simulators (Settings → Platforms) and delete old runtimes
Monthly: run the audit script above
After shipping a release: delete the archive if you've already uploaded dSYMs
Consider a cron job for DerivedData older than 30 days:

   # Add to crontab (crontab -e)
   0 3 * * 0 find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mtime +30 -exec rm -rf {} +

Beyond Xcode

If you also work with Docker, Node.js, Homebrew, Python, or other toolchains, those have their own cache bloat problems. On a multi-toolchain developer Mac, total reclaimable space can easily exceed 100 GB.

Disclosure: I'm building CleanSlateX, a macOS app that automates this audit across 13 dev toolchains and shows you every file before it deletes anything — nothing is removed without your approval. But the terminal commands above cover everything you need for Xcode specifically.

What's your DerivedData damage? Run the audit script and share your number in the comments — I'm curious how bad it gets across different setups.