DEV Community

Nic Luther
Nic Luther

Posted on

I Replaced 5 Mac Apps With One Unified Inbox — Here's What Happened

The Breaking Point

It was 2 PM on a Tuesday. I had 23 browser tabs open, 5 apps running, and I'd just missed a critical GitHub PR comment because it was buried in my Slack notifications while I was reading email in Mail.app.

Sound familiar?

Here's what my "productivity setup" looked like:

  • Mail.app for email (3 accounts, endless tabs)
  • Slack desktop for team communication (4 workspaces)
  • GitHub notifications in Chrome (always 20+ unread)
  • Calendar.app for meetings
  • Notes.app for quick captures

Each app had its own window, its own notifications, its own keyboard shortcuts. I was spending more time managing my tools than actually working.

What I Tried First: The Electron Wrapper Route

My first instinct was to find an "all-in-one" solution. I tried:

Shift — Beautiful UI, but it's essentially Chrome with tabs. RAM usage: 1.2GB for 3 email accounts + Slack. My 2020 MacBook Air was not happy.

Wavebox — Same story. Electron wrapper around web apps. Battery life dropped from 8 hours to 4 hours.

Rambox — Open source, which I loved, but still Electron. My fans kicked in every time Slack refreshed.

The pattern was clear: wrapping web apps in Electron doesn't solve the fundamental problem. You're still running multiple full Chrome instances, just in one window.

The Lightbulb Moment: What If It Was Actually Native?

I'm a developer. I've built SwiftUI apps before. And one day, frustrated with my 8th tab in Shift, I thought:

"What if I just... built a real Mac app?"

Not a wrapper. Not a web view container. A native macOS unified inbox that treats email, Slack, and GitHub as first-class data sources — not embedded web pages.

Building HeyRobyn: The Technical Approach

Here's what I learned building a native unified inbox:

1. SwiftUI Performance Is Real

My first prototype replaced Shift entirely. Memory usage dropped from 1.2GB to 50MB. Why?

  • No Chromium runtime
  • No duplicate JavaScript engines
  • Native macOS rendering (Metal-accelerated)

2. macOS Gives You Superpowers

Things that are hard in Electron are free in SwiftUI:

  • Menubar integration — One icon for everything, not 5 in the dock
  • Notification center — Real macOS notifications, not web push hacks
  • Keyboard shortcuts — System-level bindings, not JavaScript listeners
  • iCloud sync — Apple handles it, you just use CloudKit

3. Privacy-First Architecture

Because it's native, I could design for on-device everything:

  • Email parsed locally (no server)
  • Slack messages cached in local SQLite
  • GitHub data encrypted at rest
  • Zero telemetry by default (Apple App Store rules enforce this)

4. The Unified Inbox UX

The magic isn't just performance — it's one mental model for all your communication:

Inbox (Cmd+1)
├─ Email thread from Sarah
├─ Slack message from #engineering
├─ GitHub PR comment from @alex
└─ Calendar reminder: Standup in 10min
Enter fullscreen mode Exit fullscreen mode

Everything sorted by time, not by tool. You process your work chronologically, not by jumping between apps.

The Results: 4 Months In

I've been using HeyRobyn (that's what I named it) as my daily driver since November. Here's what changed:

Before:

  • 7 apps in my dock
  • 3 separate notification centers (macOS, Slack, browser)
  • 2GB RAM for communication tools
  • 4-5 hours battery life

After:

  • 1 menubar icon
  • 1 unified notification stream
  • 50MB RAM
  • 7-8 hours battery life

The unexpected benefit: I'm less distracted. When everything's in one chronological feed, I process it in batches (like email) instead of reactively switching apps every 3 minutes.

Why I'm Launching It Publicly (March 18)

For 4 months, this was my personal tool. But every time I screenshared in a Zoom call, someone asked: "What app is that?"

So I'm launching HeyRobyn publicly in 7 days:

  • Native macOS app (SwiftUI, not Electron)
  • Email + Slack + GitHub in one unified inbox
  • Privacy-first (all data on-device)
  • 50% off early access (50 spots left)

If you're tired of juggling Mail.app, Slack, and GitHub notifications, join the waitlist: heyrobyn.ai

Technical Learnings for Developers

If you're building a Mac app, here are the key decisions that made this possible:

  1. SwiftUI over AppKit — Faster development, modern reactive model
  2. CloudKit for sync — Don't roll your own backend if you can avoid it
  3. Combine for state management — Apple's reactive framework pairs perfectly with SwiftUI
  4. MailKit for email — Apple's official email framework (new in macOS 14)
  5. WebSocket for Slack RTM — Real-time messages without polling

The One Thing I'd Do Differently

I should have launched 2 months ago. Building in private is fun, but you learn 10x faster when real users are breaking your app.

If you're building a Mac productivity tool, don't wait for perfection. Ship early, get feedback, iterate.


P.S. If you're curious about the SwiftUI architecture or want to chat about Mac app development, I'm @heyrobyn on Twitter or you can reach me through the waitlist.

P.P.S. Yes, I'm still using Electron apps for some things (VS Code, Slack when I need screen sharing). But for reading and processing communication, native is the way.

Top comments (0)