Why desktop? The case for native apps
Before installing anything or writing a line of code, it is worth asking the question that most tutorials skip: why build a desktop app at all? The web is everywhere, browsers are capable, and Rails is a tool you already know. What does a native desktop application give you that a web app cannot?
The answer is not always “desktop is better.” But there is a set of problems where a native app is genuinely the right tool — and understanding that set will help you make good decisions throughout this series.
What a native desktop app gives you
Direct access to the file system. A desktop app can open, read, write, watch, and traverse files and directories without any ceremony. There are no upload dialogs, no server round-trips, no browser security sandboxes. If your app needs to work with files on disk — GPX tracks, image collections, project files, local databases — a desktop app does this naturally. A web app works around it.
A persistent process. A desktop app runs continuously. It can maintain state in memory across every action the user takes. It can watch for file changes in the background, run periodic tasks, hold an open database connection, and respond to system events — all without a server, a background job queue, or a polling mechanism.
Native look and feel. wxRuby3 uses the operating system’s own widget toolkit — Cocoa on macOS, Win32 on Windows, GTK on Linux. Your app’s buttons, menus, dialogs, and scroll bars look and behave exactly like every other app on that platform, because they are the same widgets. Users do not need to learn your UI; it already matches their muscle memory.
No network dependency. A desktop app works offline. For tools that support your own workflow — internal utilities, personal productivity apps, local data management — this often matters more than you might expect.
Performance for local data. Processing a large GPX file, generating image thumbnails, running a layout algorithm across hundreds of assets — these operations are fast when the data is local and the code runs natively. A web app would need a server round-trip, a loading state, and a progress indicator for work that a desktop app does in milliseconds.
What a web app gives you that desktop cannot match
Being honest about this is important. A web app is the right tool when:
- You need to reach users who cannot install software. Browsers are universal. Desktop apps require installation and often platform-specific builds.
- Multiple users need to collaborate on shared data. A web app has a single authoritative database. Desktop apps sharing data need a sync mechanism, which is complex.
- You need to deploy updates instantly. A web app is updated the moment you deploy. Desktop users need to update their installation.
- Your users are on devices you do not control. Phones, tablets, Chromebooks — a web app reaches all of them.
The sweet spot for wxRuby3
The apps that make most sense as wxRuby3 desktop apps share a few characteristics:
- They work with local files or local data as their primary input
- They are used by one person (or a small team on separate machines)
- They need a richer UI than a terminal script but do not need a server
- They support a workflow that benefits from persistent, responsive interaction
Internal business tools fit this description well. So do personal productivity utilities, local data management tools, and applications that wrap complex command-line workflows in a usable UI.
The applications built in Module 6 of this series — a route planner, a GPS track viewer, and an image gallery manager — are all good examples. Each works entirely with local files, benefits from a rich visual interface, and would be awkward to build as a web application.
Why wxRuby3 specifically
There are other options for building desktop apps in Ruby. The honest comparison:
Shoes is approachable but limited. It works well for simple tools but lacks the widget depth for anything complex.
Ruby/Tk ships with Ruby and requires no extra installation, but the API is dated and the visual results look out of place on modern operating systems.
wxRuby3 uses native widgets and has a large, well-documented API that mirrors the mature wxWidgets C++ toolkit. It reached its 1.0 stable release in 2024 and is actively maintained. The API is verbose compared to some alternatives, but that verbosity reflects real capability — there is almost nothing you cannot build.
If distribution to non-technical end users is a primary concern, Python with PyQt6 or wxPython has better packaging tooling right now. But for internal tools, developer utilities, and personal apps — where you control the environment and can run bundle exec ruby main.rb — wxRuby3 is a strong choice and lets you stay in the language you know.
A note on this series
The applications built throughout this series are real tools, not toy examples. By the end of Module 6 you will have a route planner that exports valid GeoJSON, a GPS track viewer that filters by date and time, and an image gallery manager that generates Hugo shortcodes. Each is built to be genuinely useful, not just to demonstrate an API.