Feature Request: Native Support for macOS (Intel/ARM) and Linux Platforms

[PatricLeal]

Is your feature request related to a problem? Please describe.
Yes. LaserGRBL currently only supports Windows, which means users on macOS and Linux cannot run it natively . This forces non-Windows users to rely on workarounds like Wine, PlayOnMac, or running a full Windows virtual machine. These methods are cumbersome and often problematic:
• On macOS (especially Apple Silicon M1/M2): Modern macOS dropped support for 32-bit executables, making it impossible to run LaserGRBL’s 32-bit Windows application via Wine without complex hacks . Apple Silicon Macs add another layer of difficulty since Wine cannot directly run x86 Windows binaries on ARM architecture . Mac users have to attempt using PlayOnMac or a virtual machine, which is slow, requires a Windows license/installation, and may not even work reliably (for example, USB/serial connections often fail under emulation). In short, Mac users (particularly those on M1/M2) are effectively shut out or face very unstable operation.
• On Linux: There is no native Linux version of LaserGRBL, so users must install it via Wine or PlayOnLinux . This involves setting up a 32-bit Wine prefix with additional components like gdiplus and Wine Mono, as recommended in the FAQ . Even after jumping through those hoops, running LaserGRBL under Wine can be fragile. Users report issues such as difficulty connecting to the serial port (needing manual COM port symlinks/registry edits) and crashes or UI glitches. For example, one user noted frequent GRBL communication stalls and display problems when using LaserGRBL with Mono/Wine on Linux . These hacks are frustrating and unreliable, especially when dealing with hardware like lasers where stability is crucial. The lack of a native build also means Linux users on modern distributions have to ensure 32-bit compatibility libraries are installed, which many systems no longer include by default. Overall, being Windows-only is a significant limitation and pain point for a large segment of the maker community.

Describe the solution you’d like
Provide official native support for macOS (both Intel x64 and ARM64) and Linux platforms. In practice, this means releasing LaserGRBL with cross-platform compatibility and offering installers for those systems. Specifically:
• macOS: Distribute LaserGRBL as a native Mac application for both Intel and Apple Silicon Macs (universal or separate binaries). For example, provide a .dmg or .pkg installer. This Mac version should not require any emulators – it should run directly on macOS and support USB serial connectivity to laser engravers out of the box. Having a native Mac build (for M1/M2 and Intel) would eliminate the need for Rosetta or Wine, greatly improving performance and stability on Mac. Users could just download LaserGRBL for macOS, install it, and use it like any other Mac application.
• Linux: Provide a native Linux build of LaserGRBL. Ideally, produce packages for common distributions (such as a .deb for Debian/Ubuntu, .rpm for Fedora/Red Hat) and/or a distro-agnostic package like an AppImage or Flatpak. An AppImage or Flatpak would let users on various distros install LaserGRBL easily without dealing with dependency hell, whereas distro-specific packages could be offered for convenience on the most popular OSes. The Linux version should be a fully native application that can access serial ports (e.g. /dev/ttyUSB0) directly, and integrate with the Linux UI environment. Native Linux support will dramatically improve usability – no more Wine setup – and ensure features like image loading and USB connectivity work reliably (which under Wine can be problematic).

By implementing native cross-platform support, LaserGRBL would become a truly universal tool for the laser engraving community. This would improve usability and stability (no more brittle emulation layers), and it would expand the user base. Many hobbyists and makers use macOS or Linux as their primary OS; offering native support means those users can adopt LaserGRBL without hesitation. It would also be a boon in educational or lab settings where Linux is common. In short, the solution is to rework/port LaserGRBL so that it runs on macOS and Linux natively, with proper installers provided, just as it currently does for Windows.

Describe alternatives you’ve considered
• Wine / PlayOnMac (Windows emulation layers): The current workaround is to run LaserGRBL through Wine on Linux or through PlayOnMac on macOS . While this can sometimes get the software running, it’s an imperfect solution. Setting up Wine requires technical steps (32-bit prefixes, installing .NET and native DLLs, etc. ), and even then the software may crash or behave incorrectly (e.g. UI hangs when opening images, serial port mapping issues). On macOS, tools like PlayOnMac rely on Wine and are further hindered by macOS dropping 32-bit support  – Wine on macOS can only run 64-bit Windows apps unless an x86 emulator is used, which LaserGRBL, being 32-bit, cannot leverage easily . Overall, while Wine/PlayOnMac can be used in a pinch, it’s not a reliable long-term method: performance is worse, USB connectivity is flaky, and every update of LaserGRBL or Wine could break something. This alternative is simply too error-prone and difficult for the average user.
• Virtual Machines (Windows in a VM): Another alternative is running a full Windows virtual machine on Mac or Linux (using VirtualBox, Parallels, VMware, etc.), just to use LaserGRBL. This does work, but it’s heavy on resources and inconvenient. Users need a licensed copy of Windows and must switch into a VM environment to run LaserGRBL, which is overkill. On Apple Silicon Macs, this approach requires running Windows on ARM (since Boot Camp is not available), which then has to emulate x86 to run LaserGRBL – a very inefficient stack. In summary, VMs provide a last-resort option, but with significant performance and complexity drawbacks.
• LightBurn (paid alternative): We’ve considered using LightBurn as an alternative software for laser control. LightBurn is a mature, cross-platform application in the same domain that does offer native Mac and Linux versions – however, it is commercial software (license costs around $100 USD for the GCode version ). Not all hobbyists can afford this, especially given that LaserGRBL is free. Moreover, relying on LightBurn is becoming less viable for Linux users: the LightBurn developers recently announced they are dropping Linux support after version 1.7 . They cited the low percentage of Linux users versus the high effort of support, and decided to sunset Linux development. This means LightBurn will no longer update on Linux, leaving Linux users stuck on old versions or forced to run the Windows version via Wine (which is exactly the scenario we’re trying to avoid!). In short, while LightBurn on Windows/macOS is an option (if one is willing to pay), it doesn’t help Linux users going forward, and it doesn’t align with LaserGRBL’s ethos of free, open-source software.
• Compiling from source / DIY ports: Since LaserGRBL is open-source, one alternative is to attempt compiling it oneself for other platforms. In practice though, this is extremely difficult and not a realistic solution for most users. The codebase is written for the .NET Framework 3.5 on Windows , using Windows-specific libraries (WinForms, GDI+, etc.). Simply compiling it on Linux or Mac isn’t straightforward – one would have to port the project to .NET Core/Mono and replace many Windows-only dependencies. Community discussions have noted that LaserGRBL has “a lot of Windows specific stuff” that prevents easy compilation on Linux/ARM without major changes . Even advanced users attempting to build for Raspberry Pi (ARM Linux) ran into roadblocks due to the x86-compiled binaries and WinForms UI not being compatible . So while “just compile it for Linux” might sound like a solution, it essentially means rewriting large portions of the application. This alternative is therefore not feasible for end-users and underscores the need for official support from the project maintainers.

Additional context
To achieve cross-platform support, LaserGRBL will likely need to be updated to a more modern and portable framework. Currently, it targets .NET Framework 3.5 , which is Windows-only and outdated. A suggested path is to migrate the project to .NET Core / .NET 6+, which supports Windows, macOS, and Linux. By moving to the modern .NET platform, the core logic (g-code streaming, image processing, etc.) can be made to run on all OSes. The GUI layer would need to be reworked since WinForms/WPF don’t exist cross-platform – but there are excellent solutions for this:
• Avalonia UI: An open-source, cross-platform .NET UI framework that can target Windows, Mac, and Linux from a single codebase . Avalonia would allow rewriting the LaserGRBL interface in XAML (similar to WPF) but have it run natively on all platforms. This could be a strong option for porting, as many .NET desktop apps have successfully migrated to Avalonia to gain cross-platform support.
• .NET MAUI or Uno Platform: .NET MAUI is Microsoft’s multi-platform App UI framework (the successor to Xamarin.Forms) and supports Windows and macOS out of the box (with community support for Linux via Gtk). The Uno Platform is another cross-platform UI layer based on WinUI/UWP paradigms. Either of these could be considered if a more native-style UI on each platform is desired. The key is that LaserGRBL’s UI would be rewritten using a cross-platform toolkit so that the same code can run on all OS environments.

By modernizing to .NET 6/7+ and a cross-platform UI, LaserGRBL could maintain one codebase and produce native executables for Windows, Mac, and Linux. This is a non-trivial effort, but it comes with long-term benefits: easier maintenance (no Wine hacks), a larger potential contributor pool, and a more future-proof architecture. The community would likely rally around such an update – developers who use Mac/Linux might join to help with the port once the project is structured for it, whereas currently they can’t easily contribute to a Windows-only .NET 3.5 project.

Importantly, expanding to Mac and Linux fills a real gap in the laser engraving software ecosystem. As mentioned, LightBurn’s discontinuation of Linux support has left many users stranded . LaserGRBL, being free and open-source, is in a perfect position to step up and become the go-to solution for those users. Providing native Linux support would attract a wave of new users (and potential contributors) who are looking for a maintained, Linux-friendly laser control software. Likewise, macOS users who have been struggling with Wine or paying for alternatives would be thrilled to have LaserGRBL available natively on their machines.

In summary, this feature request is to officially support macOS (Intel & ARM) and Linux by making LaserGRBL cross-platform. This would remove the current limitations of 32-bit Windows-only operation and open the project to a wider audience. It aligns with the spirit of the project (bringing laser engraving capabilities to as many people as possible) and ensures LaserGRBL remains relevant in a landscape where users run diverse operating systems. We understand this requires significant development work (porting to .NET Core and a new UI framework), but the payoff in terms of community goodwill, expanded user base, and longevity of the project would be well worth it. Thank you for considering this feature request!

[arkypita]

Your detailed and informative request demands an official response, one that's at least honest and explanatory. I'll have to be brief, though, because I'm on vacation. LaserGRBL was born by chance, without a plan behind it, without the expectation that it would become what it is today. The small, day-to-day improvements I made in my spare time have made it a good, simple, and unpretentious program, which today boasts 160,000 active users. I agree that, being one of the few free software programs so widely available, it would be great to be able to provide more. There are many ideas, both in terms of new features, usability, and cross-platform support. The program deserves to be rewritten from scratch, but I currently have zero time for that. So, unfortunately, I have to say that development has almost stopped, and I can't address what you're asking for. From the way you wrote your message you must be experienced and competent enough to understand that what you propose would require me to dedicate myself full time to this work, unfortunately my work and my family do not allow me to do this, However, if anyone would like to embark on this undertaking I am more than willing to provide all my know-how

[PatricLeal]

Thank you very much for your honest and kind reply, especially while you're on vacation.

I completely understand your situation — I also have a full-time job, attend university, and have a family, so I can only dedicate time to development in my spare moments.

Still, I truly believe in the value of LaserGRBL and what you’ve built over the years. It's a powerful and inspiring open-source project that has helped thousands of makers and professionals — including myself.

That said, I’d be happy to contribute and help bring LaserGRBL to other platforms (macOS, Linux) as a community initiative. I plan to carefully evaluate the project’s structure and begin prototyping a cross-platform implementation based on your work.

I may need some technical guidance along the way — especially to understand how you handled some of the more advanced GRBL logic or GCode features — and I really appreciate your willingness to assist with that when possible.

I hope that this small effort can help extend the legacy you’ve already established and open the door for more contributors and users around the world.

Thanks again for keeping this project alive for so long. I’ll keep you posted as I make progress.