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
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:
- SwiftUI over AppKit — Faster development, modern reactive model
- CloudKit for sync — Don't roll your own backend if you can avoid it
- Combine for state management — Apple's reactive framework pairs perfectly with SwiftUI
- MailKit for email — Apple's official email framework (new in macOS 14)
- 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)