DEV Community: heocoi

Building MailSink: a temp email API with MCP server on Cloudflare Workers

heocoi — Wed, 22 Apr 2026 00:35:35 +0000

The problem

Testing email flows in CI has been painful for years. MailSlurp is $79/mo, Mailtrap's API isn't built for AI agents, and most alternatives want you to run your own SMTP server.

I wanted something different: a REST API callable from tests, with an MCP server so AI agents could run email-verified signup flows natively.

So I built it.

What it does

MailSink gives you programmatic temporary email inboxes via a simple REST API:

# Spin up a disposable inbox
curl -X POST api.mailsink.dev/v1/inboxes
# → signup-k8m2@codenotify.net

# Your app or agent signs up with that address...

# Wait for the verification mail, extract the OTP code
curl api.mailsink.dev/v1/inboxes/inb_rae1z/wait-for-code
# → { "code": "847291", "from": "stripe.com" }

That's the whole API surface for the common case.

The MCP angle

An MCP server ships in the @mailsink/mcp npm package. Claude Code, Cursor, Windsurf, any MCP client can call these tools natively during autonomous workflows:

create_inbox({ ttl: 3600 })
// → signup-k8m2@codenotify.net

get_verification_code({ inbox_id, timeout: 30 })
// → { code: "847291" }

Your agent can actually sign up for Stripe, GitHub, Clerk, Supabase. Not a browser automation wrapper. Native.

The architecture

Everything runs on Cloudflare's edge:

workers/api - Hono on Cloudflare Workers. Routes: inboxes, messages, domains, keys, auth (GitHub OAuth), billing (Stripe), internal. KV-based rate limiting.
workers/email - Cloudflare Email Routing handler. Parses incoming mail with postal-mime, writes metadata to D1, raw body to R2, triggers OTP extraction.
packages/shared - OTP + magic-link extractors for Stripe, GitHub, Google, Clerk, Supabase, Auth0, Resend, AWS. Raw MIME always available if the extractor misses.
mcp - @mailsink/mcp npm package. 7 tools exposed to MCP clients.

Why Cloudflare:

Sub-20ms p50 latency via 320+ edge locations
Email Routing handles SMTP receipt for free on shared domains
D1 for metadata, R2 for bodies, zero infra to manage
One deploy target, one config

What I learned

Email parsing is harder than it looks. postal-mime handles MIME well, but OTP patterns across senders are wildly inconsistent. I built per-sender extractors for the top 8 services and fall back to generic regex patterns for everything else.
MCP turned a dev tool into an agent tool. Same REST API, new audience. Zero additional code to maintain, major differentiator in the pitch.
Cloudflare Email Routing + shared domains lets you skip running Haraka or Postfix for shared-domain inboxes. You only need your own SMTP receiver when you support Bring Your Own Domain.
Pricing anchors matter. MailSlurp at $79/mo signals "enterprise." I priced Pro at $15/mo because the real differentiator is agent-friendliness, not feature parity.

Pricing

Free: 3 inboxes, 100 msgs/mo
Pro: $15/mo unlimited
BYOD on Pro+ (bring your own domain, waitlist)

Try it

Live at https://mailsink.dev. GitHub OAuth, you're in in 10 seconds.

Feedback welcome, especially on API shape and pricing positioning.

First open stable release. Still learning what breaks.

I built a $19/mo dunning tool because Churn Buster costs $249

heocoi — Mon, 23 Mar 2026 16:55:34 +0000

The problem

If you run a SaaS on Stripe, around 9% of your MRR is silently leaking every month. Cards expire. Banks decline. Customers don't notice.

Stripe retries the charge a few times, but it doesn't email your customers. It doesn't warn them their card is about to expire. And by the time you notice, they've already churned.

The existing solutions are expensive

I looked at the options:

Churn Buster: $249/mo minimum
Baremetrics Recover: $158/mo
Stunning: opaque MRR-based pricing

For an indie founder doing $5-25K MRR, spending $150-250/mo on dunning feels wrong. The ROI math works, but the cash flow doesn't.

So I built Revenudge

Revenudge does three things:

1. Pre-dunning alerts - Detects cards expiring in 30/14/7 days and emails your customers BEFORE the payment fails. This is the killer feature. Stripe doesn't do this.

2. Recovery email sequences - When a payment does fail, sends 3 branded emails (Day 1, 3, 7) with a one-click card update link. Your logo, your colors, your brand.

3. Recovery dashboard - Track MRR at risk, recovered revenue, recovery rate, email open/click rates. Know exactly how much money you're saving.

Tech stack

Next.js (App Router) on Vercel
Supabase (Postgres + Auth + RLS)
Stripe Connect (OAuth, webhooks)
Resend (transactional emails)

One-click Stripe Connect setup. No API keys to paste. 60 seconds from signup to protected.

Pricing

Starter: $19/mo (up to $5K MRR)
Growth: $39/mo (up to $25K MRR)
Scale: $79/mo (up to $100K MRR)

14-day Growth trial, no credit card required.

Try it

If you're running subscriptions on Stripe and losing revenue to failed payments, give it a shot: revenudge.com

Built by an indie dev, for indie devs. Happy to answer questions in the comments.

Your printer hates your designs. So I made them print-ready by default.

heocoi — Sun, 15 Mar 2026 05:29:38 +0000

I just shipped Inkpress - an AI-powered tool that generates print-ready business cards, flyers, posters, and restaurant menus from text prompts.

The problem

Small business owners design something that looks great on screen, send it to a printer, and get back cards with white edges, blurry logos, or colors that look completely different. The gap between "looks good on my monitor" and "prints correctly" is surprisingly wide.

Print design has a bunch of technical requirements that have nothing to do with design taste:

Bleed: 3mm of artwork extending past the cut line so you don't get white edges
Safe zone: keeping text 3-5mm inside the trim so it doesn't get clipped
Resolution: 300 DPI minimum (screens are 72-96 DPI)
Color mode: CMYK instead of RGB, because ink and light mix differently

Most people don't know about any of this until their first print job comes back wrong.

What Inkpress does

You describe what you want in plain text. Something like: "Business card for my photography studio, name Sarah Chen, dark minimal style." Inkpress generates 3 design variations, all print-ready from the start. You pick one, then refine it through conversation - change colors, swap fonts, adjust layout - until it's right. Export a PDF and send it to any print shop.

Every export includes proper bleed, trim marks, safe zone guides, and 300 DPI resolution. The user never has to think about print specs.

Tech stack

Frontend: React + Vite + Tailwind CSS
Backend: Hono (lightweight, runs anywhere)
Database: better-sqlite3 (simple, no separate server)
AI: Claude API for both design generation and iterative refinement
Auth: Google OAuth via better-auth
Storage: Cloudflare R2 for generated assets
Hosting: Railway (backend) + Cloudflare (DNS/CDN)

The design generation works by having Claude output structured HTML/CSS for each design variation. The frontend renders the designs in real-time, and the export pipeline converts them to print-ready PDFs with correct dimensions and bleed.

Lessons learned so far

Print specs are surprisingly standardized. Business cards are 85x55mm (EU) or 88.9x50.8mm (US). Bleed is always 3mm. Once you encode these rules, the AI can apply them consistently every time.

Conversational iteration > form-based editing. Early prototypes had sliders and dropdowns for every design parameter. Turns out "make the font bigger and move the logo to the left" works way better than a settings panel.

Generating 3 variations beats generating 1. Users almost never love the first output. But when they see 3 options side by side, they can articulate what they want by pointing at what they like from each one.

It's live at inkpress.app. Would love to hear feedback, especially from anyone who's worked with print design or AI-assisted creative tools.

I built an on-device duplicate photo finder for iPhone (and why I avoided the cloud)

heocoi — Wed, 25 Feb 2026 16:40:23 +0000

My camera roll had over 12,000 photos. A lot of them were near-identical shots I never cleaned up - bursts, multiple takes of the same thing, old screenshots.

I tried a few duplicate cleaners. Most only caught exact pixel duplicates. That helped maybe 1% of the problem.

So I built Snapsift.

What it does

Scans your photo library, groups photos that look similar (not just exact copies), and helps you keep one best shot from each group.

scans the full library in under a minute
groups near-duplicate photos side by side
picks a candidate "best shot" in each group based on sharpness
lets you delete the extras

Why on-device only

The obvious path was to send photos to a server, run similarity matching there, and return results. Cheaper to build, easier to iterate.

I didn't do that for two reasons.

First, privacy. Uploading someone's personal photos to a server - even temporarily - is a trust problem I didn't want to create.

Second, Apple's Vision framework is actually good enough to do this locally. The image embedding and similarity matching runs fast on modern iPhones. No server needed.

Zero outbound network calls. Photos never leave the device.

Technical notes

The core of the app is image feature extraction via Vision's VNGenerateImageFeaturePrintRequest. It generates a compact embedding for each photo, then I cluster similar embeddings together using cosine distance.

"Best shot" selection looks at estimated sharpness (Laplacian variance on a downsampled version) and basic composition heuristics. It is not perfect but it is right most of the time.

PhotoKit handles library access. The whole scan pipeline runs in a background task so the UI stays responsive.

Business model

Free to scan the full library. Free tier allows deleting up to 25 photos per month. One-time lifetime purchase available.

Current status

Would like feedback on:

whether the grouping accuracy holds up on large real-world libraries
cases where the "best pick" is clearly wrong
any UX friction in the review flow

App Store: https://apps.apple.com/us/app/snapsift/id6759221222
Landing page: https://snapsift.app

How to Check if Your VPN is Working on Mac: DNS Leak Testing Guide

heocoi — Sun, 25 Jan 2026 08:24:31 +0000

Your VPN icon shows "connected." Your ISP can still see everything you're doing.

DNS leaks. IPv6 leaks. WebRTC leaks. Your VPN can be active while your traffic leaks around it. Here's how to know if your VPN is actually protecting you—and how to fix it when it's not.

The Problem: VPN ≠ Privacy

Most people assume their VPN works because the app says "connected." That's not enough.

What actually happens:

You connect to a VPN server in Switzerland
Your Mac sends DNS requests to your ISP (leak)
Your ISP sees every website you visit
Your VPN did nothing

This is a DNS leak—your DNS queries bypass the VPN tunnel. Your ISP, government, or network admin can see your browsing history even though you're "protected."

Why it happens:

macOS defaults to system DNS servers
VPN apps don't always override DNS properly
IPv6 traffic can bypass VPN entirely
VPN disconnect without killing internet (no kill switch)

Lesson: The VPN icon in your menu bar lies. You need to verify.

The 3 Types of VPN Leaks

1. DNS Leak (Most Common)

What it is: Your DNS requests go to your ISP instead of your VPN's DNS servers.

Why it matters: DNS queries reveal every domain you visit. If your ISP handles DNS, they see your browsing history regardless of VPN encryption.

How to detect: If a DNS leak test shows your ISP's DNS servers instead of your VPN provider's, you're leaking.

2. IPv6 Leak

What it is: Your Mac uses IPv6 internet traffic that bypasses the VPN tunnel.

Why it matters: Most VPNs only tunnel IPv4. If you have IPv6 enabled, that traffic leaks your real location and identity.

How to detect: If an IPv6 test shows your real ISP IPv6 address while connected to VPN, you're leaking.

3. WebRTC Leak (Browser-Based)

What it is: Browsers can expose your real IP address through WebRTC, even with VPN connected.

Why it matters: Websites can detect your true IP despite the VPN.

How to detect: If a WebRTC test shows your real IP alongside the VPN IP, you're leaking.

Manual Testing: The Free Way

You can test for leaks manually using online tools. Here's the process:

Step 1: Check Your Baseline IP

Before connecting to VPN:

Visit ipleak.net
Note your real IP address and location
Note your ISP's DNS servers

This is what you're trying to hide.

Step 2: Connect to VPN

Connect to your VPN:

Choose a server in a different country
Wait for connection to establish
Verify VPN app shows "connected"

Step 3: Test for DNS Leaks

Check DNS servers:

Visit dnsleaktest.com
Click "Extended Test"
Wait for results

What to look for:

✅ Good: DNS servers belong to your VPN provider or are in the VPN server's country
❌ Bad: DNS servers belong to your ISP or show your real location

Step 4: Test for IPv6 Leaks

Check IPv6 address:

Visit test-ipv6.com
Check if IPv6 address is detected

What to look for:

✅ Good: "No IPv6 address detected" or VPN provider's IPv6 address
❌ Bad: Your real ISP IPv6 address shows up

Step 5: Test for WebRTC Leaks

Check browser leaks:

Visit browserleaks.com/webrtc
Look at "Local IP Address" section

What to look for:

✅ Good: Only VPN IP addresses appear
❌ Bad: Your local network IP (192.168.x.x or 10.x.x.x) appears

Quick fix for WebRTC leaks:

Use browser extensions like "Disable WebRTC" (Chrome/Firefox)
Or disable WebRTC in browser settings

Fixing Common Leaks

Fix DNS Leaks

Option 1: Use VPN's DNS servers

Check if your VPN app has "Use VPN DNS" option
Enable it in VPN settings
Reconnect and retest

Option 2: Manually set DNS in macOS

Open System Settings → Network
Select your network connection
Click Details → DNS
Remove ISP DNS servers
Add VPN provider's DNS servers

Option 3: Enable VPN kill switch

Most VPN apps have this feature
Blocks all internet if VPN disconnects
Prevents accidental leaks

Fix IPv6 Leaks

Option 1: Disable IPv6 (Recommended)

Most VPNs don't support IPv6. Safest to disable it:

Open System Settings → Network
Select your connection → Details
Go to TCP/IP tab
Set "Configure IPv6" to Link-local only
Click OK

Option 2: Use VPN with IPv6 support

Mullvad, IVPN, and some others support IPv6
Verify with their documentation

Fix WebRTC Leaks

Browser settings:

Safari:

Safari doesn't leak WebRTC by default (Apple disabled it)

Chrome:

Install "WebRTC Leak Prevent" extension
Or use Brave browser (blocks by default)

Firefox:

Type about:config in address bar
Search for media.peerconnection.enabled
Set to false

Automatic Monitoring vs. Manual Testing

Problem with manual testing:

You have to remember to check
VPN can disconnect silently while you work
Leaks can start mid-session
Testing every site visit is impractical

Example scenario:

You connect to VPN before work
VPN silently drops connection during a Zoom call
You browse for 2 hours without noticing
ISP logs everything

macOS doesn't alert you when VPN disconnects. You might not notice for hours.

Lesson: One-time tests are snapshots. Continuous monitoring catches problems immediately.

Automated VPN Monitoring Tools

Several tools provide persistent monitoring:

Built-in: macOS System Preferences

What it shows:

Active VPN connection indicator (lock icon)
VPN on/off status

Limitations:

No leak detection
No alerts on disconnect
No DNS/IPv6 verification

Best for: Basic awareness that VPN is connected (not that it's working correctly).

Third-Party: VPN Provider Apps

Most VPN apps include:

Connection status
Server selection
Kill switch option

Limitations:

Don't test for leaks
Assume DNS routing is correct
No verification of actual traffic flow

Best for: Connecting to VPN, but not verifying privacy.

VPN Peek

A dedicated menu bar leak monitor.

Pros:

Real-time DNS leak detection
IPv6 leak checking
Alerts when VPN disconnects
Auto-refresh leak tests at intervals
Shows current IP and location

Cons:

Requires separate app
Not built into VPN client

Best for: Users who want continuous verification without manual testing.

Choosing the Right VPN for Mac

Not all VPNs handle macOS properly. Look for:

1. Native macOS App

Why it matters: Native apps integrate better with macOS network stack.

Avoid: Browser extensions (leak prone), manual OpenVPN configs (complex)

2. Kill Switch Feature

What it does: Blocks all internet if VPN disconnects

Why essential: Prevents accidental leaks between disconnect and reconnect

Test it: Disconnect VPN manually, try browsing. Should be blocked.

3. DNS Leak Protection

What to look for:

"Use VPN DNS" or "DNS leak protection" toggle
Custom DNS servers option
Automatic DNS override

Test it: Run DNS leak test with feature on/off

4. IPv6 Handling

Options:

IPv6 support: VPN tunnels IPv6 traffic (rare)
IPv6 blocking: VPN disables IPv6 to prevent leaks (common)
No handling: You must disable IPv6 manually (bad)

Recommended VPNs with good macOS support:

Mullvad (open source, IPv6 support, kill switch)
IVPN (privacy-focused, leak protection)
ProtonVPN (secure core, NetShield)

(This is not sponsored. These just handle macOS correctly.)

When to Test Your VPN

Daily Routine

Morning: Verify VPN connected and no leaks before starting work

Why: VPN might have disconnected overnight, DNS settings can reset

After Network Changes

Test after:

Switching WiFi networks (home → coffee shop)
macOS updates
VPN app updates
Changing VPN servers

Why: Network changes can break VPN routing

Random Spot Checks

Test during:

Before accessing sensitive accounts
When using public WiFi
When browsing from restricted locations

Why: VPN can fail silently. Regular verification catches issues.

Common macOS VPN Issues

"VPN Connected" but Internet Doesn't Work

Cause: Split tunneling or routing conflict

Fix:

Disconnect VPN
Flush DNS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Reconnect VPN
Test connection

DNS Requests Still Go to ISP

Cause: macOS not respecting VPN DNS servers

Fix:

System Settings → Network → Advanced → DNS
Remove all DNS servers
Add only VPN provider's DNS
Drag VPN DNS to top of list
Apply changes

VPN Keeps Disconnecting

Cause: Firewall or antivirus interference

Fix:

Check System Settings → Network → Firewall
Add VPN app to allowed list
Disable "Block all incoming connections"
Restart Mac

My Recommendation

For most Mac users, here's the practical approach:

Initial Setup (One-time)

Test your VPN manually using ipleak.net and dnsleaktest.com
Fix any leaks before relying on VPN
Enable kill switch in VPN app settings
Disable IPv6 unless your VPN supports it

Ongoing Monitoring

Option A: Manual (Free)

Test weekly with online leak tests
Check before sensitive browsing
Requires discipline

Option B: Automated

Use menu bar monitor like VPN Peek
Get alerts on disconnect or leaks
Continuous peace of mind

You don't need paranoia-level checking. But you should verify your VPN works more than once.

The Bottom Line

The VPN icon in your menu bar only tells you the app is connected. It doesn't tell you if your privacy is protected.

DNS leaks, IPv6 leaks, and silent disconnections happen frequently. macOS won't warn you.

Test manually:

Use ipleak.net, dnsleaktest.com, test-ipv6.com
Check after setup and network changes
Free but requires manual checking

Monitor automatically:

VPN Peek for continuous leak detection
Alerts when VPN fails
Persistent visibility in menu bar

Pick based on your threat model. If you use VPN casually for geo-unblocking, manual tests are fine. If you rely on VPN for privacy or work remotely with sensitive data, automated monitoring catches failures before they matter.

Either way, "connected" doesn't mean "protected." Verify.

Continuous VPN monitoring and leak detection from your Mac menu bar. Get instant alerts when your VPN disconnects or DNS/IPv6 leaks are detected—no manual testing required.
Menu Bar DNS Leak Test IPv6 Detection

👉 Download via App Store

How to Monitor Battery Health on Mac: Built-in vs Third-Party Apps

heocoi — Sat, 17 Jan 2026 02:28:25 +0000

Your MacBook battery is a consumable. After enough charge cycles, it degrades. Knowing when that degradation happens—before your laptop dies mid-presentation—is worth a few minutes of setup.

Here's how to monitor battery health on macOS, from built-in tools to dedicated apps.

The Built-in Method: System Information

Apple provides basic battery stats in System Information. Here's how to access them:

Hold Option and click the Apple menu
Select System Information
Navigate to Hardware → Power

You'll see:

Cycle Count — How many full charge cycles the battery has completed
Condition — Apple's assessment (Normal, Replace Soon, Service Battery)
Full Charge Capacity — Current maximum capacity in mAh
Health Information — Maximum capacity percentage (macOS 11+)

For a quick check, this works. Apple considers batteries "healthy" until they drop below 80% of original capacity or reach their rated cycle count (typically 1000 cycles for modern MacBooks).

Limitation: You have to dig through menus every time. No persistent monitoring, no alerts, no history.

When Built-in Tools Fall Short

System Information tells you the current state. It doesn't tell you:

How fast your battery is degrading
Whether your charging habits are causing damage
Real-time power consumption by apps
Temperature during charging (heat kills batteries)

If you charge to 100% every night and leave it plugged in, you're accelerating wear. If you frequently drain to 0%, same problem. The built-in tools won't warn you.

Lesson: Apple's tools show status. They don't help you improve habits.

Third-Party Apps: The Options

Several apps fill this gap. Here's an honest comparison.

coconutBattery (Free / $10 Pro)

The veteran. coconutBattery has been around since 2005 and remains reliable.

Pros:

Shows detailed battery stats
Tracks history over time
Can read iPhone/iPad battery health via USB
Pro version adds menu bar display

Cons:

Interface feels dated
Pro version required for menu bar
No charging management features

Best for: Users who want detailed stats and iPhone monitoring.

AlDente (Free / $22 Pro)

Focused on extending battery lifespan through charge limiting.

Pros:

Limits maximum charge level (e.g., cap at 80%)
Heat protection features
Good for users who stay plugged in

Cons:

Doesn't monitor health—manages charging
Overkill if you use your laptop unplugged often
Pro version required for advanced features

Best for: Desktop-mode users who stay plugged in most of the time.

Battery Vitals

A lightweight menu bar utility focused on at-a-glance monitoring.

Pros:

Clean, minimal interface
Menu bar icon shows current health
One-click access to key stats
No configuration required

Cons:

Fewer features than coconutBattery
No charge limiting like AlDente

Best for: Users who want simple, persistent monitoring without complexity.

What Metrics Actually Matter

Apps show dozens of numbers. Focus on these three:

1. Cycle Count

One cycle = using 100% of battery capacity (not necessarily in one session). Using 50% today and 50% tomorrow equals one cycle.

Modern MacBooks are rated for 1000 cycles before dropping to 80% capacity. If you're at 800 cycles and battery health is still 95%, you're doing well. If you're at 300 cycles and health is 85%, something's wrong.

2. Maximum Capacity

This percentage shows how much charge your battery holds compared to when it was new. 100% is factory condition. Below 80% is "degraded" by Apple's standards.

The rate of decline matters more than the current number. Losing 5% in two years is normal. Losing 5% in three months suggests a problem.

3. Temperature During Charging

Batteries degrade faster when charged hot. If your MacBook runs hot (resource-intensive apps, poor ventilation), battery wear accelerates.

Some apps show charging temperature. If you consistently see temps above 35°C (95°F) during charging, consider improving airflow or limiting intensive tasks while plugged in.

Lesson: Track trends, not just snapshots. A single reading tells you little.

My Recommendation

For most users, a lightweight menu bar app provides the right balance.

Here's my approach:

Glance at the menu bar — See current health without opening anything
Check detailed stats monthly — Look for unusual degradation
React to alerts — If health drops suddenly, investigate

You don't need to obsess over battery stats. You need to catch problems before they strand you without power.

System Information works for occasional checks. But if you want persistent awareness without thinking about it, a menu bar utility is worth it.

Practical Habits That Actually Help

Beyond monitoring, these habits extend battery life:

Avoid extreme charge levels — The 20-80% range is gentlest on lithium-ion batteries
Don't leave it plugged in at 100% indefinitely — Modern macOS has Optimized Battery Charging to help, but it's not perfect
Keep it cool — Don't charge while running intensive tasks if avoidable
Update macOS — Apple occasionally improves battery management in software updates

Monitoring tells you when these habits aren't working. That's its value.

The Bottom Line

Apple's built-in tools provide basic battery stats. They require manual checking and don't track history or provide alerts.

Third-party apps fill the gap:

coconutBattery for detailed analysis and iOS device monitoring
AlDente for charge limiting if you're always plugged in
Battery Vitals for simple, persistent menu bar monitoring

Pick based on your usage pattern. If you're frequently mobile and want to catch degradation early, a lightweight monitor like Battery Vitals makes sense. If you're docked most of the time, AlDente's charge limiting might extend your battery's lifespan.

Either way, knowing your battery health beats being surprised when it fails.

I built a Mac app to stop exceeding my mobile data cap

heocoi — Wed, 14 Jan 2026 14:27:28 +0000

Ever tethered from your iPhone for "just a quick Zoom call" and ended up burning through half your monthly data?

Yeah, me too. Multiple times.

The problem

macOS doesn't distinguish between your home WiFi and your iPhone hotspot. Activity Monitor shows total bandwidth, but not "how much data did I use specifically on this limited connection?"

Existing solutions either:

TripMode ($15/year) - Overkill. I don't need app blocking, just awareness
Bandwidth+ (Free) - Doesn't know the difference between hotspot and home WiFi

So I built HotspotPeek

A simple menu bar app that:

Detects hotspot connections using NWPathMonitor.isExpensive
Tracks data per session and per month
Supports multiple profiles (personal phone, work phone, travel MiFi)
Alerts before you hit your cap

Technical bits

Built with SwiftUI + AppKit (NSMenu for native feel). Uses:

NWPathMonitor for connection type detection
CoreWLAN for SSID identification (to auto-switch profiles)
Pure system frameworks, no external dependencies

macOS 14+ only because I wanted to use the @Observable macro.

Lessons learned

Sweet spot matters - Found the gap between "too basic" and "overkill"
Location permission UX - Needed for SSID access on Sonoma+, had to explain clearly why
Menu bar apps - NSMenu > NSPopover for authentic macOS feel

This is part of my "Peek" series - simple utilities that surface hidden macOS info:

VPN Peek (VPN status + leak detection)
Signal Peek (WiFi signal strength)
Battery Vitals (battery health)
Storage Peek (disk info)

Available on the Mac App Store for $4.99 one-time purchase.
No BS subscriptions.

https://apps.apple.com/us/app/hotspot-peek/id6757591640?mt=12

What's your experience with data caps? Any features you'd want to see?

Why I Build macOS Menu Bar Apps

heocoi — Mon, 12 Jan 2026 14:27:49 +0000

Building software has always been about solving problems for me. Not big, world-changing problems necessarily, but the small frustrations that add up throughout the day. The kind of friction that makes you think, "There has to be a better way."

That's how I got into building macOS menu bar apps.

The Appeal of Menu Bar Apps

Menu bar apps occupy this unique space in the macOS ecosystem. They're always accessible, yet unobtrusive. They live in the background, ready when you need them, invisible when you don't. This constraint—having to be useful while taking up minimal screen real estate—forces you to focus on what truly matters.

I love that challenge.

Each app I build is designed around a single purpose. Battery Vitals monitors your battery health. Storage Peek shows you what's eating your disk space. SignalPeek keeps tabs on your network. One tool, one job, done well.

Why Minimal Matters

We live in an age of feature creep. Apps that start simple inevitably accumulate buttons, settings, and capabilities until they become bloated and confusing. I've fallen into that trap before, adding features because I could, not because I should.

With menu bar apps, there's a natural pressure to stay minimal. You simply don't have the real estate to add unnecessary complexity. This constraint is liberating. It forces me to make hard choices about what stays and what goes.

The result? Apps that are easier to build, easier to maintain, and—most importantly—easier to use.

Building for Myself (And Others Like Me)

Every app I've built started as a tool I needed for myself. I got tired of diving into System Preferences to check my battery health. I wanted a quick way to visualize my storage without waiting for Finder to analyze my drives. I needed network stats at a glance.

Building for my own needs keeps me honest. I can't hide behind market research or user personas. If I wouldn't use it daily, why would anyone else?

But here's the beautiful part: when you build something genuinely useful for yourself, you often discover there are thousands of other people with the same problem. That's when an indie project becomes something bigger.

The Joy of Shipping

There's something deeply satisfying about shipping a complete product. Not a feature, not a component, but a whole thing that someone can download and use immediately. Menu bar apps, by their nature, are small enough to ship regularly.

This rapid feedback loop "build, ship, iterate" keeps me motivated. I'm not working on something for months before users see it. I can release an MVP in weeks, get real feedback, and improve from there.

What's Next

I'm continuing to explore this space. There are so many small problems worth solving, so many opportunities to build something minimal and useful. Each app teaches me something new about design, development, and what people actually need versus what they think they want.

If you're thinking about building your own macOS apps, my advice is simple: start small, solve your own problems, and don't be afraid to ship something minimal. The world doesn't need another bloated feature-rich app. It needs more tools that do one thing exceptionally well.

That's what I'm building. One menu bar app at a time.

What I Learned Building a Native macOS Menu Bar App

heocoi — Thu, 08 Jan 2026 13:39:56 +0000

I just shipped VPN Peek - a menu bar utility for macOS — and the journey taught me more about AppKit than I expected.

Here's what I wish someone told me before I started.

NSPopover vs NSMenu: Choose Wisely

Most tutorials show NSPopover for menu bar apps. It's easy — just attach a SwiftUI view and you're done.

But it never felt right. The popover has a slight delay, doesn't dismiss naturally, and looks like a "floating app" rather than a system utility.

I switched to NSMenu with custom views:

let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength)

let menu = NSMenu()
let customItem = NSMenuItem()
customItem.view = NSHostingView(rootView: YourSwiftUIView())
menu.addItem(customItem)

statusItem.menu = menu

The difference? It feels like a real Mac app now. Instant open, standard dismiss behavior, native animations.

Lesson: If your app lives in the menu bar, make it feel like it belongs there.

The Hybrid Trap

"Just use SwiftUI" is tempting advice. But menu bar apps hit SwiftUI's edge cases fast:

Window management is weird
Menu styling is limited
Some AppKit APIs have no SwiftUI equivalent

I ended up with roughly 70% SwiftUI, 30% AppKit. SwiftUI for views and state, AppKit for system integration.

Don't fight it. Embrace the hybrid.

Sandbox Will Break Your Heart

My original feature list was ambitious. Then I met macOS sandbox.

Things I couldn't do in a Mac App Store app:

Access other apps' network connections
Read system logs
Monitor processes

Half my "cool ideas" died here. But honestly? It forced me to focus. The app does fewer things, but does them well.

Tip: Check sandbox limitations before you design features, not after.

Small Details That Matter

Some things I obsessed over that users actually noticed:

Adaptive menu bar icon. Light icon on dark menu bar, dark icon on light. Sounds obvious, but many apps get this wrong.

statusItem.button?.image = NSImage(named: "MenuIcon")
statusItem.button?.image?.isTemplate = true // This one line handles dark/light mode

Proper number formatting. "1234 ms" vs "1,234 ms" vs "1.2s". Tiny detail, but it signals polish.

No Dock icon. Menu bar apps shouldn't clutter the Dock.

<!-- Info.plist -->
<key>LSUIElement</key>
<true/>

These aren't features. They're expectations. Miss them and your app feels off.

App Store Review: Expect the Unexpected

My first submission was rejected. Reason? The app "didn't have enough functionality."

I added a few quality-of-life features, resubmitted, approved.

No logic change. Just perception.

Lesson: Reviewers spend seconds on your app. Make sure it looks complete at first glance.

What I'd Do Differently

Start with NSMenu from day one. I wasted time on NSPopover before accepting it wasn't right.

Build the preferences window early. I kept hardcoding values during development. Technical debt adds up.

Target macOS 14+ and don't look back. Modern Swift features like @Observable are worth dropping older OS support.

Worth It?

Building for macOS is humbling. The platform has opinions, and fighting them is painful.

But when everything clicks — when your app feels like it belongs on macOS — that's satisfying in a way web development never gave me.

VPN Peek is on the Mac App Store if you want to see the result.

And I'm launching on Product Hunt this Saturday (Jan 10) if you want to support the journey.

Happy to answer questions about menu bar development in the comments 👇