Overseer
Torna al Blog
Why Native Apps Still Matter for System Monitoring
macOS
Native
SwiftUI
System Monitoring
EN

Why Native Apps Still Matter for System Monitoring

20 gennaio 2026
Team Overseer

In 2026, the lines between "web app" and "desktop app" have blurred more than ever. With frameworks like Electron, Tauri, and Progressive Web Apps (PWAs), a developer can ship a single codebase to macOS, Windows, and Linux. It is enticing. It is efficient. And for many use cases (like Slack or Notion), it is entirely sufficient.

However, "sufficient" is not "excellent."

At Overseer, we made the conscious choice to build a 100% native macOS system monitoring dashboard using Swift and SwiftUI. We didn't choose the easy path of wrapping a web app in an Electron container. We chose the path of craftsmanship. Here is why we believe native apps still matter for system monitoring—and why they always will.

1. The Resource Tax (RAM and Battery)

The most obvious difference is efficiency.

Electron/Web Architecture

An Electron app is essentially a dedicated instance of Google Chrome running locally.

  • Base RAM Footprint: ~150MB just to render "Hello World".
  • CPU: JavaScript is single-threaded and JIT-compiled.
  • Battery: Chrome is notorious for eating battery. Each tab (or app view) is a separate process.

Native Architecture (Swift)

A native app compiles to binary machine code (ARM64 for Apple Silicon).

  • Base RAM Footprint: ~15-30MB.
  • CPU: Direct access to the Metal API and multi-threading via Grand Central Dispatch.
  • Battery: macOS aggressively optimizes native apps, suspending background activities efficiently.

For a system monitoring tool that you might keep running 24/7 alongside development tools, browsers, and virtual machines, we didn't want to be the reason your MacBook spins its fans or drains its battery.

2. Accessibility is Not Optional

Accessibility (a11y) is often an afterthought in web development, requiring manual ARIA attributes and rigorous testing.

In the native Apple ecosystem, standard UI controls (Buttons, Lists, Charts, TextFields) come with VoiceOver support built-in.

  • Semantic Structure: The OS understands the hierarchy of your views.
  • Navigation: Keyboard navigation follows system standards automatically.
  • Contrast & Dynamic Type: Native apps respect the user's system-wide font size settings immediately.

By building native, Overseer's monitoring dashboards are usable by system administrators and developers with visual impairments out of the box, without us having to "re-implement" accessibility for complex charts and visualizations.

3. Deep System Integration

A native app doesn't just live on your computer; it lives with it.

The Services Menu

Select performance data in any app -> Right Click -> Services -> "Analyze in Overseer". This is trivial in AppKit, impossible in a web app.

Shortcuts & Automation

Overseer exposes intent definitions to the Shortcuts app. You can build a workflow:

  1. "Check system performance"
  2. "Export monitoring report"
  3. "Alert if CPU exceeds threshold"
  4. "Generate daily performance summary" All automated, all native.

Spotlight

Native apps can index their content. You can search for "CPU usage trends" or "network performance reports" in Spotlight and jump directly into those monitoring views in Overseer.

4. The "Uncanny Valley" of UI

Web apps can mimic native UI, but they often fall into the "Uncanny Valley"—something feels slightly off.

  • Scrolling Physics: iOS and macOS have very specific inertial scrolling curves ("rubber banding"). Web implementations often try to emulate this with JavaScript, but it rarely feels perfect.
  • Windows Management: Native apps handle multiple windows, tabs, and split views in a standard way.
  • Key Bindings: Cmd+comma for Preferences. Cmd+H to hide. Standard text editing shortcuts (Option+Left/Right). These are muscle memory for Mac users.

5. Security and Sandboxing

Native apps distributed via the Mac App Store run in a strictly enforced Sandbox.

  • They cannot read arbitrary files without your permission (Powerbox).
  • They cannot capture your screen or keystrokes without explicit system consent.
  • They are code-signed and notarized by Apple.

Web apps typically run with fewer restrictions or, conversely, are stuck inside a browser sandbox that limits system monitoring access entirely (necessitating the Electron wrapper which then often asks for too much permission).

6. The Developer Experience (SwiftUI)

From a developer perspective, SwiftUI has matured. Creating a performant real-time chart with 100,000 data points in a web DOM is complex (canvas rendering, WebGL optimizations). In SwiftUI:

Chart {
    LineMark(
        x: .value("Time", dataPoints.map(\.timestamp)),
        y: .value("CPU Usage", dataPoints.map(\.cpuUsage))
    )
}

The system handles the rendering, the memory management, and the real-time updates. We can spend our time building monitoring features, not fighting the rendering engine.

Conclusion

We aren't saying web apps are bad. For collaborative tools like Figma, the web is the perfect platform. But for a high-performance utility tool like a System Monitoring Dashboard—where you deal with real-time metrics, complex visualizations, and deep system integration—the raw power and efficiency of a native application usually wins.

Overseer is our love letter to the Mac. It respects your battery, your memory, and provides real insights into your system's performance. That is why native matters for system monitoring.