DEV Community: Nic Luther

How do you manage notification overload from email, Slack & GitHub?

Nic Luther — Thu, 12 Mar 2026 11:46:15 +0000

I have been obsessed with this problem. As developers, we constantly switch between email, Slack, and GitHub notifications. I tracked mine: 47 app switches per day, about 25 minutes wasted on context switching alone.

I started building a solution called HeyRobyn — a native Mac app that puts all three in one window (SwiftUI, not Electron, all data on-device). But I am curious:

How do YOU manage notification overload?
Do you use any unified inbox tools?
Would you actually want email + Slack + GitHub in one app, or does separation help you focus?

Genuinely want to hear different perspectives.

Building a Native Mac Unified Inbox with SwiftUI: Email, Slack & GitHub in One Window

Nic Luther — Thu, 12 Mar 2026 02:31:47 +0000

Why I Built a Unified Inbox for Mac

I was context-switching 50+ times a day between Gmail, Slack, and GitHub. Each notification would pull me out of flow, and important messages got buried across multiple apps.

After trying every productivity app on the market (Shift, Wavebox, Rambox), I realized they all had the same fundamental problem: they're Electron apps that just wrap web pages. Heavy, slow, and not truly native to macOS.

So I built HeyRobyn - a native SwiftUI unified inbox for Mac.

Technical Decisions

Why SwiftUI Over Electron?

The performance difference is night and day:

Memory: 150MB vs 800MB+ for Electron competitors
Battery: Native APIs mean better power efficiency
Speed: No web view overhead - instant UI updates
Mac-native feel: Proper keyboard shortcuts, Touch Bar support, macOS design patterns

Architecture Overview

┌─────────────────────┐
│   SwiftUI Views     │  ← Native UI layer
├─────────────────────┤
│  Core Data Models   │  ← Local-first storage
├─────────────────────┤
│   API Integrations  │  ← Gmail, Slack, GitHub SDKs
│   (OAuth2 + PKCE)   │
└─────────────────────┘

Everything runs on-device. No cloud sync means:

Privacy: Your emails never touch our servers
Speed: No network latency for UI operations
Offline: Full functionality without internet

The Hardest Part: OAuth2 Flow

Getting OAuth2 working natively in SwiftUI (without a web view) was surprisingly complex. Here's the key pattern I landed on:

// Simplified OAuth2 PKCE flow
class AuthManager: ObservableObject {
    @Published var isAuthenticated = false

    func authenticate(service: Service) async throws {
        // 1. Generate PKCE challenge
        let codeVerifier = generateCodeVerifier()
        let codeChallenge = generateChallenge(from: codeVerifier)

        // 2. Open system browser for consent
        let authURL = buildAuthURL(challenge: codeChallenge)
        NSWorkspace.shared.open(authURL)

        // 3. Listen for callback via custom URL scheme
        let authCode = try await waitForCallback()

        // 4. Exchange code for tokens
        let tokens = try await exchangeCodeForTokens(
            code: authCode, 
            verifier: codeVerifier
        )

        // 5. Store securely in Keychain
        try KeychainService.store(tokens, for: service)
        isAuthenticated = true
    }
}

This pattern works for Gmail (Google OAuth), Slack, and GitHub.

Unified Inbox Logic

The core challenge: how do you merge 3 different message types into one chronological feed?

I created a protocol-oriented approach:

protocol UnifiedMessage: Identifiable {
    var timestamp: Date { get }
    var sender: String { get }
    var preview: String { get }
    var source: MessageSource { get } // .email, .slack, .github
    var priority: Priority { get }
}

// Each integration implements this protocol
struct EmailMessage: UnifiedMessage { ... }
struct SlackMessage: UnifiedMessage { ... }
struct GitHubNotification: UnifiedMessage { ... }

// Unified feed is just a sorted array
var feed: [UnifiedMessage] = [
    emails, slackMessages, githubNotifications
].flatMap { $0 }
 .sorted { $0.timestamp > $1.timestamp }

AI Triage: The Secret Sauce

I integrated local ML models (Core ML) to auto-categorize and prioritize messages:

Urgent: Mentions from your manager, security alerts, build failures
Important: PR reviews, direct messages, project updates
Low priority: Marketing emails, automated notifications, FYIs

This runs entirely on-device using Apple's Natural Language framework:

import NaturalLanguage

func categorizePriority(for message: UnifiedMessage) -> Priority {
    let tagger = NLTagger(tagSchemes: [.sentimentScore])
    tagger.string = message.content

    // Check for urgency keywords
    if message.content.containsUrgentKeywords() {
        return .urgent
    }

    // Analyze sender importance
    if importantContacts.contains(message.sender) {
        return .important
    }

    return .low
}

Lessons Learned

1. SwiftUI is Amazing (But Has Sharp Edges)

List performance: For 1000+ items, use LazyVStack + custom diffing, not List
State management: Combine's @Published + ObservableObject works great
Navigation: SwiftUI's NavigationStack is still buggy - sometimes need UIKit bridges

2. Privacy-First Is Hard But Worth It

Users are extremely sensitive about email privacy. Going 100% local-first was the right call:

No backend to maintain or secure
No GDPR compliance headaches
Users trust the app more (visible in feedback)

3. Distribution on Mac Is Unique

App Store: 30% fee + sandboxing restrictions (can't access Mail.app data)
Direct distribution: Code signing costs $99/year, notarization takes time
Pricing: Mac users expect either $10 one-time OR $5-15/mo subscription

I went with direct distribution + subscription ($12.50/mo early access).

What's Next

I'm launching HeyRobyn publicly on March 18, 2026. Early access waitlist: heyrobyn.ai

Planning to add:

Linear integration (project management)
Discord (for open source communities)
Custom integrations via plugin API

Would love feedback from the community:

What other integrations would you want?
Any concerns about the privacy model?
Mac developers: what's your unified inbox setup?

Tech stack: SwiftUI, Core Data, Combine, Core ML, OAuth2 PKCE

Waitlist: https://heyrobyn.ai

How I Handle 200+ GitHub Notifications Without Losing My Mind

Nic Luther — Tue, 10 Mar 2026 20:49:49 +0000

Last Tuesday, I opened GitHub and saw 247 unread notifications. PRs from 6 different repos, security alerts, code review requests, mentions in issues I commented on 3 months ago, Dependabot spam, and a release announcement for a library I starred once in 2019.

I spent 2 hours triaging. By the time I finished, I had 89 new notifications waiting.

The Context-Switching Tax

Here's what my workflow looked like before I fixed this:

Email notification → "John mentioned you in issue #4523"
Switch to browser → Open GitHub, find the issue
Read context → 47 comments, scroll to find my mention
Slack ping → "Can you review my PR?"
Switch to Slack → Click the link (opens another browser tab)
Back to email → Dependabot opened 12 PRs
Repeat forever

Every context switch costs ~23 minutes to regain focus (UC Irvine research). I was losing 2+ hours daily just switching between GitHub, Slack, and email.

What I Tried (And Why It Failed)

Attempt 1: Email Filters

I set up Gmail filters to auto-label GitHub notifications by repo. Helped slightly, but:

Still required opening each notification in a browser
No way to prioritize PRs vs issue comments vs releases
Slack and email remained separate

Attempt 2: GitHub CLI + Terminal Workflow

gh pr list --assignee @me
gh issue list --mentions @me

Great for scripting, but:

Had to remember syntax for every query
Couldn't see Slack threads or emails in the same view
No visual diff preview without opening browser

Attempt 3: Browser Extensions

Tried Refined GitHub, Octotree, and 5 others. They made GitHub's UI better but didn't solve the core problem: notifications were still scattered across 3 apps.

The Unified Inbox Epiphany

I realized I didn't need better GitHub notifications — I needed one place to see:

GitHub PRs awaiting my review
Slack threads where I'm mentioned
Emails that require action
All sorted by urgency, not chronology

So I built it. HeyRobyn is a native Mac app (SwiftUI, not Electron) that pulls GitHub, Slack, and email into a single unified inbox.

How It Works (Technical Overview)

1. GitHub API Integration
Uses GitHub's REST API + webhooks to fetch:

PRs filtered by review status (review_requested, changes_requested)
Issues where I'm mentioned or assigned
Release notifications (only for repos I've contributed to, not starred)

2. Intelligent Prioritization
Sort algorithm:

priority_score = (
  base_urgency +
  (is_blocking_others ? 50 : 0) +
  (review_requested_by_teammate ? 30 : 0) +
  (security_alert ? 100 : 0) -
  (age_in_hours * 0.5)
)

3. On-Device Data Storage
Everything cached locally in SQLite. No server middleman. Privacy-first.

4. Native macOS Performance
SwiftUI means:

50MB RAM (vs 1.2GB for Electron-based tools)
Instant search across all messages (Core Spotlight integration)
Keyboard-first navigation (Cmd+K to jump anywhere)

The Result

Before:

247 GitHub notifications
42 unread Slack threads
89 emails
7 browser tabs open
2GB RAM consumed
2+ hours/day triaging

After:

1 unified inbox
12 items marked "urgent" (the rest auto-filtered)
1 Mac window
50MB RAM
20 minutes/day triaging

What Changed (Beyond the Time Saved)

The real win isn't time — it's mental clarity.

Before: Every notification felt urgent because I couldn't see the full picture.

After: I can see at a glance:

"3 PRs are blocking teammates" → review now
"14 Dependabot PRs" → batch-merge later
"87 GitHub notifications" → muted repos I don't actively maintain

I'm no longer reactive. I decide what matters.

Try It Yourself

HeyRobyn launches March 18 with 50% off early access. We're at 47 waitlist signups — targeting 100 by launch.

If you're drowning in GitHub notifications, Slack pings, and email chaos, check out heyrobyn.ai or see how it compares to tools like Shift and Wavebox.

Built with SwiftUI. Data stays on your Mac. No Electron bloat.

What's your GitHub notification strategy? Do you triage daily, weekly, or just let them pile up? Drop a comment — genuinely curious how other devs handle this.

How I Handle 200+ GitHub Notifications Without Losing My Mind

Nic Luther — Tue, 10 Mar 2026 20:36:32 +0000

How I Handle 200+ GitHub Notifications Without Losing My Mind

Last Tuesday, I had 247 unread GitHub notifications. By Wednesday afternoon, I'd missed a critical PR review that blocked my team for 6 hours. By Thursday, I'd decided enough was enough.

If you're a developer working on multiple repos, you know the pain: GitHub notifications pile up faster than you can triage them. Mix in Slack pings, email threads, and calendar alerts, and you're spending 2+ hours a day just staying on top of communication.

Here's how I went from drowning in notifications to processing 200+ GitHub items in under 30 minutes a day — and why I eventually built a unified inbox to solve this permanently.

The Problem: Death by Context Switching

My old workflow looked like this:

Morning routine (90 minutes):

Open Mail.app → check email (15 min)
Open Slack → respond to DMs, scan channels (25 min)
Open GitHub notifications page → triage issues/PRs (35 min)
Check calendar in yet another app (5 min)
Realize I missed a Slack thread → back to Slack (10 min)

Result: By 10 AM, I'd already context-switched 12+ times and hadn't written a single line of code.

The real killer wasn't the volume of notifications — it was the cognitive overhead of switching between 3-4 apps just to understand what needed my attention.

What I Tried First

Attempt 1: GitHub email notifications

GitHub lets you receive all notifications via email. Sounds great, right?

Reality: My inbox became a graveyard of [user/repo] Issue #1234 emails. Threading broke constantly. Finding the original context meant opening GitHub anyway. Abandoned after 2 weeks.

Attempt 2: Slack integrations

Connected GitHub to Slack via webhooks. Every PR, issue comment, and mention posted to a #github channel.

Reality: The channel moved so fast I started muting it. Then I missed important mentions. Plus, I still had to check actual GitHub for the full thread. Abandoned after 1 week.

Attempt 3: Browser tabs + notifications

Kept GitHub, Slack, and Gmail pinned in Chrome tabs. Enabled desktop notifications for everything.

Reality: Notification fatigue set in. I started ignoring all notifications because most were noise. Battery life tanked (Chrome + Slack Desktop = 2-3 hours). Gave up after 3 weeks.

The Breaking Point

The moment I knew I needed a real solution: I got pinged in Slack about a PR that was blocking a deploy. The PR had been ready for review for 6 hours, but it was buried under 40 other GitHub notifications I hadn't triaged yet.

I'd spent the morning bouncing between email, Slack, and GitHub, yet somehow missed the most important thing.

That's when I realized: the problem wasn't the tools. It was the fragmentation.

What Actually Works: The Unified Inbox Approach

I started sketching out what a solution would look like:

Core principle: One window, one chronological feed, smart filtering.

Key features needed:

Pull GitHub notifications, Slack DMs, and email into a single stream — no more app-hopping
Filter by priority — separate "needs review" from "FYI"
Preserve context — show the full thread without opening a browser
Native Mac app — no Electron memory hog (looking at you, Slack Desktop)
Privacy-first — all data stays on my machine

Why I Built It in SwiftUI

I tried Electron first. It worked, but:

Memory usage: 1.2 GB for a basic prototype
Battery drain: 30-40% per day just running in the background
Startup time: 3-4 seconds cold launch

Switched to SwiftUI (native macOS):

Memory usage: 50 MB (24x improvement)
Battery drain: negligible (macOS optimizations for native apps)
Startup time: instant (app icon bounce = ready)

For a tool I'd use 10+ hours a day, performance mattered.

The Technical Stack

Here's how I approached the GitHub notifications problem specifically:

GitHub API integration:

// Fetch all unread notifications
let notifications = try await github.notifications.list(all: false)

// Filter by reason (review_requested, mention, etc.)
let prioritized = notifications.filter {
    ["review_requested", "mention", "assign"].contains($0.reason)
}

// Group by repo for easy triage
let grouped = Dictionary(grouping: prioritized) { $0.repository.name }

Smart filtering rules:

Priority 1: PRs I'm requested to review, direct @mentions
Priority 2: Issues I'm assigned to, team mentions
Priority 3: Thread subscriptions, repo watching

Key insight: GitHub's API exposes a reason field that tells you why you got the notification. Most third-party tools ignore this. Using it to auto-prioritize cut my triage time by 60%.

The Result

My current workflow (30 minutes):

Open one app in the morning
See GitHub PRs needing review, Slack DMs, and urgent emails in one unified feed
Filter by "needs action" vs "FYI"
Process high-priority items first
Archive or snooze the rest

Time saved: 60 minutes/day = 5 hours/week = 20 hours/month.

The On-Device Privacy Win

One requirement I refused to compromise on: no cloud server processing my data.

Most "unified inbox" tools (Shift, Wavebox, etc.) are just Chromium wrappers that load the web UIs. They don't actually unify anything — you're still using Gmail's web UI, Slack's web UI, GitHub's web UI in separate tabs.

My approach:

GitHub: Pull notifications via API, store locally in SQLite
Slack: Use Slack API, decrypt messages on-device
Email: IMAP connection, emails stored locally

Why this matters: My GitHub repos include proprietary code. Slack has customer conversations. Email has contracts. I'm not sending that to a third-party server just to get a unified feed.

What I'd Do Differently

If I were starting over:

Start with MVP filtering logic — I spent 2 weeks on UI polish before nailing the smart filters. Should've been reversed.
Test with 1000+ notifications immediately — My initial prototype choked on large volumes. Real-world testing would've caught this.
Add keyboard shortcuts from day 1 — Power users (me) live in shortcuts. I bolted them on later; should've been core UX.

Should You Build Your Own?

Build it if:

You're drowning in cross-app notifications daily
You care about data privacy (no cloud processing)
You want native performance (not Electron)
You enjoy solving your own problems with code

Don't build it if:

You're fine with browser tabs + discipline
You don't mind Electron memory usage
You need Windows/Linux support (SwiftUI = macOS only)

For me, this was a no-brainer. I'm a Mac developer who spends 10 hours/day in communication tools. Building a native unified inbox paid for itself in saved time within 2 weeks.

The Launch

I'm opening up early access on March 18, 2026 (7 days from now). If you're curious how it compares to Shift, Wavebox, or Rambox, I wrote up a detailed comparison here: heyrobyn.ai/compare

50% off for the first 50 signups. I built this to solve my own problem — if it helps you too, that's a win.

TL;DR:

GitHub notifications + Slack + email = 2 hours/day lost to context switching
Tried email routing, Slack integrations, browser tabs — all failed
Built a native macOS unified inbox in SwiftUI (50 MB RAM vs 1.2 GB Electron)
Used GitHub API's reason field to auto-prioritize notifications
All data stays on-device (no cloud server)
Cut triage time from 90 min → 30 min/day

If you're handling 100+ GitHub notifications weekly, this might resonate. If not, stick with your current setup — no shame in browser tabs if they work for you.

What's your notification triage workflow? Would love to hear what's working (or not working) for you.

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

Nic Luther — Tue, 10 Mar 2026 20:10:23 +0000

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.

Why We Chose SwiftUI Over Electron for Our Mac App

Nic Luther — Tue, 10 Mar 2026 19:08:42 +0000

The Performance Difference Is Staggering

When we started building HeyRobyn, our native Mac unified inbox for email, Slack, and GitHub, we faced a critical architectural decision: should we build with Electron (like most modern desktop apps) or go native with SwiftUI?

The performance numbers made the choice clear:

Memory: 50MB (SwiftUI) vs 500MB+ (typical Electron app)
Startup time: Instant vs 3-5 seconds
CPU usage: Minimal vs constant background activity
Battery impact: Native efficiency vs noticeable drain

Why SwiftUI Made Sense for HeyRobyn

1. Native Scrolling and Gestures

One of the first things users notice about HeyRobyn is how it feels like a real Mac app. That's because it is. SwiftUI gives us:

Buttery-smooth scrolling powered by macOS's optimized rendering engine
Native keyboard shortcuts that respect system preferences
Proper support for trackpad gestures (pinch to zoom, swipe navigation)
System-level integration (Touch Bar, notifications, Spotlight)

2. Privacy-First Architecture

We built HeyRobyn with a core principle: all your data stays on your device. No cloud sync, no server-side processing. SwiftUI made this natural because:

Direct access to macOS security features (Keychain, App Sandbox)
No web server running in the background (unlike Electron's Chromium)
Native file system access with proper permissions
Encrypted storage using Apple's security frameworks

3. Your MacBook's Fans Will Thank You

Electron apps are notorious for spinning up fans and draining batteries. We've all had that meeting where your laptop sounds like a jet engine because Slack and VS Code are fighting for resources.

With SwiftUI, HeyRobyn runs at 50MB RAM — less than a single Chrome tab. Your system monitor will barely register it's running.

The Challenges We Faced

Building native isn't all rainbows. Here's what we had to work through:

Learning curve: SwiftUI is relatively new (2019) compared to web technologies. Finding solutions to niche problems meant diving into Apple's documentation rather than Stack Overflow.

Platform-specific: We can only support macOS. If we wanted to ship on Windows or Linux, we'd need to rebuild from scratch.

Fewer third-party libraries: The npm ecosystem dwarfs Swift Package Manager. We built more components from scratch than we would have with Electron.

Why It's Worth It

Seven days until launch, and we're confident we made the right choice. When users try HeyRobyn, the first thing they notice isn't the features — it's how fast and native it feels.

In 2026, most developers are wrapping websites in Electron and calling them desktop apps. We went the other direction. We built a real Mac app that respects your hardware, your privacy, and your time.

HeyRobyn launches March 18, 2026. First 50 waitlist signups get 50% off forever ($0.50/month). Join at heyrobyn.ai

Building in public, shipping fast. Follow our journey at @heyrobyn