Where to go from here
You have reached the end of the wxRuby3 Desktop Development tutorial series. This is a good moment to take stock of what you have built, what wxRuby3 is genuinely good for, and where its limits are.
What you have learned
Working through this series you have covered the full arc of wxRuby3 desktop development:
Module 1 established the desktop mindset — the event loop, the frame-panel-widget hierarchy, and why desktop thinking is different from web thinking.
Module 2 gave you the building blocks — the core widgets, sizer layout, menus and toolbars, and standard dialogs.
Module 3 covered the patterns that make real apps possible — multi-file structure, model/panel separation, inter-panel communication via callbacks, file I/O, preferences, threading with the GIL, and the format converter as a practical capstone.
Module 4 moved into rich output — device context drawing, image handling, RichTextCtrl, HtmlWindow, and a live markdown editor.
Module 5 added WebView — the full browser engine embedded in your app, the JavaScript bridge for bidirectional Ruby/JS communication, live Chart.js dashboards, Leaflet maps, and the markdown editor upgraded with syntax highlighting.
At each stage you built something runnable. The apps in this series are not toy examples — the format converter, the markdown editor, the sensor dashboard, and the Leaflet map viewer are all genuinely useful tools.
What wxRuby3 is good for
wxRuby3 shines in specific contexts:
Internal tools for Ruby teams. If your team already runs Ruby for web development, adding a native desktop tool requires no new runtime infrastructure. A wxRuby3 app can sit alongside your Rails codebase, share models and business logic, and give developers a proper native interface for tasks that don’t belong in a browser.
Personal productivity apps. Tools you build for yourself or your immediate colleagues — log analysers, file processors, image tools, data converters — work beautifully with wxRuby3. The target audience is comfortable with gem install and a terminal.
Prototyping. wxRuby3 lets you build a working native desktop prototype quickly in a language you already know. If the prototype proves the concept, you can decide later whether to rewrite it in something with better distribution story.
Small team tools with a known environment. If you are distributing within an organisation where you can say “install Ruby 3.x and run gem install wxruby3”, wxRuby3 is entirely practical. A one-time setup script handles the prerequisites.
Wrapping Ruby business logic in a native UI. If you have existing Ruby code — parsers, models, API clients — wxRuby3 lets you build a proper desktop interface around it without rewriting the logic.
Where wxRuby3 has limits
Distribution to non-technical users is genuinely hard. Packaging a wxRuby3 app for someone who does not have Ruby installed requires bundling a Ruby runtime, the wxRuby3 native extension with its embedded wxWidgets binary, and all your app’s gem dependencies. The tooling for this — Tebako, Traveling Ruby — works for some gems but the wxRuby3 native extension is large and non-standard. At the time of writing, no clean one-step packaging solution exists for wxRuby3 on all platforms. This will improve as the ecosystem matures.
It is a niche project. wxRuby3 is maintained by a small team. The API is comprehensive and the quality is high, but the community is small compared to Electron, PyQt, or even wxPython. When you hit an unusual problem, you may be reading C++ wxWidgets documentation or filing a GitHub issue rather than finding a Stack Overflow answer.
If you need to ship to strangers, consider alternatives. For apps that need broad distribution to non-technical users who won’t install Ruby, the honest answer is that other tools — Electron, Tauri, PyInstaller, or native Swift/SwiftUI on macOS — have better packaging stories today. wxRuby3 is excellent for what it does, but wide distribution is not currently its strength.
The right mental model
wxRuby3 occupies a useful niche: it is the best way to build a native desktop app in Ruby, for an audience that has Ruby. That audience is larger than you might think — Rails teams, Ruby tool authors, developers who want a proper desktop interface on their scripts — and for them, wxRuby3 is genuinely the right choice.
Think of it the way you think of a well-made internal Rails app: not packaged for the App Store, but exactly right for the people who will use it.
What comes next
Distribution. The packaging problem is real and worth solving. A future post will cover the current state of wxRuby3 distribution — what actually works, what the tradeoffs are, and how to set up a target machine for a wxRuby3 app. The landscape is moving and a dedicated, regularly-updated guide will serve better than a tutorial chapter that goes stale.
Real-world apps. The route planner, GPS track viewer, and gallery tiler mentioned in Module 5 are all real applications built on the patterns in this series. Blog posts covering each of these in depth — the interesting architecture decisions, the bugs encountered, the wxRuby3 quirks discovered — are better suited to standalone write-ups than tutorial chapters.
WebView in depth. Module 5 introduced the WebView and the JavaScript bridge. There is more to cover — eCharts for richer data visualisation, more sophisticated Leaflet usage with offline tiles and route planning, and the full bidirectional bridge pattern applied to complex applications.
Thank you
wxRuby3 is a remarkable piece of work. mcorino has built something that genuinely fills a gap in the Ruby ecosystem, and the quality of the library — the API design, the documentation, the prebuilt binary packages — reflects years of careful work. If this series has been useful, consider contributing to wxRuby3: report bugs, open pull requests, or simply use it and share what you build.
End of the wxRuby3 Desktop Development Tutorial Series