HarborDB
Back to Blog
Why Native Apps Still Matter in 2026
macOS
Native
SwiftUI

Why Native Apps Still Matter in 2026

January 20, 2026
Team HarborDB

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 HarborDB, we made the conscious choice to build a 100% native macOS application using Swift, SwiftUI, and AppKit. We didn't choose the easy path of wrapping a React app in a Chromium container. We chose the path of craftsmanship. Here is why we believe native apps still matter—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 database tool that you might keep open all day alongside Xcode, Docker, and Chrome, we didn't want to be the reason your MacBook spins its fans.

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, 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, HarborDB is usable by developers with visual impairments out of the box, without us having to "re-implement" accessibility.

3. Deep System Integration

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

The Services Menu

Select text in any app -> Right Click -> Services -> "Query in HarborDB". This is trivial in AppKit, impossible in a web app.

Shortcuts & Automation

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

  1. "Get latest backup from S3"
  2. "Unzip"
  3. "Import to HarborDB"
  4. "Run Query" All automated, all native.

Spotlight

Native apps can index their content. You can search for "UserTable schema" in Spotlight and jump directly into that table definition in HarborDB.

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 file system 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 list of 100,000 items in a web DOM is complex (virtual scrolling, recycling). In SwiftUI:

List(items) { item in
    ItemRow(item: item)
}

The system handles the virtualization, the memory management, and the scrolling performance. We can spend our time building 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 Database Client—where you deal with millions of rows, complex queries, and local files—the raw power and integration of a native application usually wins.

HarborDB is our love letter to the Mac. It respects your battery, your memory, and your workflow. That is why native matters.