
How I built SysMonitor, an open-source macOS resource monitor that tracks CPU, RAM, and Network with zero clutter.
I recently open-sourced SysMonitor, a native macOS menu bar app for tracking system resources like CPU, RAM, Disk I/O, and Network speeds.
I built it because I was tired of the two extremes in the macOS monitoring ecosystem: tools that give you just a tiny text readout in the menu bar with no details, or massive dashboards that look like an airplane cockpit. I wanted a clean menu bar readout that drops down into a gorgeous, translucent widget only when I need it.
Here's how I put it together using 100% Swift and SwiftUI, and the workarounds I used to make it feel truly native.
NSPopover for Custom GlassmorphismWhen you build a menu bar app, the standard Apple way to show a dropdown is using NSPopover. It handles the positioning and the little arrow pointing to the menu bar icon
automatically.
But NSPopover has strict visual constraints. It wraps your content in a border and doesn't easily let you achieve edge-to-edge transparency or custom glassmorphism.
Instead, I opted to build a custom, borderless NSWindow backed by an NSVisualEffectView:
// Create a borderless, transparent window
window.titlebarAppearsTransparent = true
window.titleVisibility = .hidden
window.isOpaque = false
window.backgroundColor = .clear
// Add the glassmorphism backdrop
let visualEffect = NSVisualEffectView()
visualEffect.blendingMode = .behindWindow
visualEffect.material = .hudWindow
visualEffect.state = .active
visualEffect.autoresizingMask = [.width, .height]
This gave me the exact visual style I wanted—a frosted glass panel floating over the desktop—but it meant I had to manually calculate exactly where the window should appear on the screen.
Because I wasn't using NSPopover, the widget window had no idea where the menu bar icon was. To make it feel like a dropdown, I had to grab the coordinates of the NSStatusItem
button and position the window relative to it.
Here's the logic inside the AppDelegate:
if let button = statusItem?.button, let _ = button.window?.screen {
// 1. Get the button's bounds and convert to global screen coordinates
let buttonFrameInWindow = button.convert(button.bounds, to: nil)
let buttonFrameInScreen = button.window!.convertToScreen(buttonFrameInWindow)
let windowWidth = window.frame.width
let windowHeight = window.frame.height
// 2. Center the window horizontally under the button
let xPos = buttonFrameInScreen.midX - (windowWidth / 2)
// 3. Place it just below the menu bar
let yPos = buttonFrameInScreen.minY - windowHeight - 5
// 4. Update the frame
window.setFrame(NSRect(x: xPos, y: yPos, width: windowWidth, height: windowHeight), display: true)
}
This guarantees the window snaps perfectly underneath the icon, regardless of whether the user has a notch, an external monitor, or moves the icon around in their menu bar.
One of the biggest issues with system monitors is that polling sysctl and calculating CPU ticks in the background can actually consume a lot of CPU, draining your MacBook
battery just to tell you your battery is draining.
To fix this, SysMonitor throttles itself. When the glass widget is visible, it polls every 2 seconds for a smooth UI. But when you click away, the window listens for
windowDidResignKey, auto-hides with a quick fade-out animation, and dials the polling back to every 5 seconds.
extension AppDelegate: NSWindowDelegate {
// Hide the widget window automatically when the user clicks elsewhere
func windowDidResignKey(_ notification: Notification) {
if let window = widgetWindow, window.isVisible {
hideWidgetWindow() // Fades out and drops polling rate to 5s
}
}
}
The end result is exactly what I wanted: a fast, native tool that tells me what I need to know and then gets out of my way.
You can check out the full source code (and grab the build) over on GitHub:
{% github fanioz/sysmonitor %}
Discussion Question: When you build background utilities for macOS or Windows, how do you balance the polling frequency with battery life constraints? Do you stick to fixed intervals or dynamically throttle based on app visibility? Let me know below!
aiMost of us have seen a coding agent fail to complete a task we know it can do. We just don't...
googlecloudWhen building Generative AI applications, developers often encounter a massive bottleneck: sequential...
discussI’ve been thinking about sharing some electronic circuit posts on Dev.to — small circuits, DIY...
agentsWhat nobody tells you about exporting your multi-agent prototype to a local workspace. Every...
agenticarchitectAutonomous agents are genuinely good at answering messy business questions. Give one an LLM and a set...
aiPR volume went up, ticket quality didn't, and the gap got filled with LLMs on both sides of the review: bots reviewing, bots replying, bots occasionally arguing with bots about priorities that only existed in a teammate's head. Our CEO named the actual problem, and it's bigger than code review.
Workflows from the Neura Market marketplace related to this Stable Diffusion resource