Introduction

As summer begins, the pull between productivity and procrastination becomes progressively powerful and writing something meaningful becomes more and more deprioritized. Since for the sake of starting my blog, I have to have something written here anyways, I’d rather publish something that is both informative and interesting (so at least reading becomes less of a chore in this season). On that note I’d like to explain the nuances of making a multiplatform app and why one of my best projects so far, Geepac, remains locked to Linux and as a result not published yet.

Inconveniences (or Issues?)

While modern technology has come a long way and writing apps on an open platform like the Personal Computer is easier than ever, don’t let it trick you into believing that everything from conceptualizing to publishing is a task for the faint of heart. Starting off, writing a cross-platform desktop application requires handling entirely different operating system platform-specific APIs and conflicting core OS behaviors.

For example, here’s how Windows, Linux and macOS handle file paths:

Windows:

• Uses drive letters followed by a colon and a backslash (e.g., C:\ or D:).
• Case-insensitive but case-preserving; File.txt and file.txt point to the exact same file.
• Home directory is typically stored under C:\Users\Username\

Linux:

• Uses a single forward slash (/) as the universal root directory for everything.
• Strictly case-sensitive; File.txt and file.txt are two completely different files.
• Home directory is /home/username/

macOS:

• Same as Linux, uses a single forward slash (/) as the universal root directory.
• Case-insensitive by default (using the APFS file system) but can be formatted to be case-sensitive.
• Home directory is located under /Users/username/

Just these few changes by themselves are enough to cause a rewrite for your core app logic for every single different Operating System you want to support but fret not, the challenges have only just begun.

The Real Obstacle

While reading the above might make you feel inconvenienced, that doesn’t stop developers (including me) from making clever code adjustments to work around the way files are handled on each Operating System. Thankfully, there exist libraries such as the C/C++ Standard Library that give you handy code snippets to determine your platform and adjust paths on the fly saving massive rewrites. However, there exists another major challenge, that is delivering a native user experience across different design languages used by the different OSes. Example, Windows uses Fluent design with specific window controls, macOS follows strict Human Interface Guidelines with the menu bar at the top of the screen, and Linux has competing desktop environments like GNOME and KDE Plasma. Even if you manage to somehow work the internals, getting the app to ‘draw’ correctly is a separate challenge on its own.

Fortunately, devs before us thought of this and made frameworks like Electron or Flutter to help developers share UI code across platforms but these frameworks struggle to mimic these native nuances perfectly, thus causing the app to feel sluggish, heavy, or out of place on at least one platform. It also forces developers to constantly tweak layout margins, font rendering, and keyboard shortcuts to fit each specific environment. Furthermore, these frameworks also waste tonnes of hardware resources because the solution they employ is to spin up a web browser instance to provide a common ‘canvas’ for the apps in question. So while yes, they do solve the coding problem, the testing, deployment, and maintenance workloads still triple for multi-platform development.

The Fix

As of writing this, there is no universally accepted fix for the problems discussed above. Each company, team and developer choose what approach works best for them. Personally, using ImGui, a universal C++ library for SimpliFile was the solution I went with for my future app. It provides a low enough memory and compute overhead to not cause performance issues while still offering a comprehensive set of tools that can be used to build a functioning app. Ultimately, what path you choose comes with what goals you want to achieve with your app. If you target even more platforms, like Android and iOS, then web based choices like Electron still remain the definitive choice despite the performance penalties because it makes maintenance that much more easier. If you were satisfied with PCs, then perhaps something like ImGui or each platform’s native toolkits like GTK for GNOME (Linux) or .NET for Windows might suit your palate more.

With all this being said, I leave you to your success until the next time. Happy Coding!