Cross Platform GUI Development Is Hard


by Andreas Schipplock

Introduction

Today I had a conversation about how cross platform gui development can be accomplished as easy as possible and whenever one asks that himself the first time he might be in that illusion that cross platform gui development can be easy and that it's not a hard thing to accomplish but whenever one is thinking like that he is probably just wrong.

The first idea many people come across is to develop the gui application in Java most likely with the SWING gui toolkit which is shipped with SUN's java distribution and which can be used to create cross platform gui applications that almost look native and almost feel native. Most people fear SWING because they got reminded of the old times where swing had the metal look by default which was a lot of a difference to what the native os widgets looked like.

However, today JAVAs SWING toolkit is not the worst idea if you want to go cross platform. You can deploy your application to linux, windows and even os-x but you will fight with a big drawback that almost any SWING application has to fight with: a slow gui. There are SWING based java applications that are quite responsive but the majority just feels slow. They don't even need to _be_ slow but they feel slow and for a desktop application there is this one criteria that's very important but underrated by most programmers: startup-time.

Startup-time for a desktop application is very important as the user, when he clicks the icon of the application, expects the app to be started immediately. It's a simple criteria but it exists and as you know the java virtual machine takes quite some time to start up which is not a problem for server based software but for desktop apps it is.

If you still want to go the java route and hate swing there is an alternative which in fact is quite a good idea. It's called SWT, is part of eclipse and implements the native ui of the os specifically so if you want to deploy your app on os-x you'll have to ship the os-x jar explictly. The drawback is that there aren't many gui builder available (there is one which seems buggy).

There are some other gui libraries for java but the most stable are AWT, Swing and SWT which you can consider to use if you want to develop cross platform gui applications.

If you aren't the java guy, but like c++, the fastest way to develop cross platform gui applications is to use Qt from Nokia. Really, the lib is one of the best you may come across when hacking c++ plus Nokia gives you the Qt IDE for free which is a killer app productivity-wise. Learning the Qt API is also very easy if you are used to programming in general and building for different platforms is a breeze. The only drawback is the license which is restrictive if you want to modify the core of Qt itself. If you just want to develop your next commercial software on top of Qt it's absolutely no problem but it's still a bitter taste in your mouth. Consider this license 'issue' when you are doing serious development.

So what else do we have to cross develop gui applications? C with Gtk? C++ with FLTK? Flex? Na'we want it native! Almost at least!

Depending on what specific operating systems you want to support it may change your decision on what to use. If you are just want to target Windows and Linux it's easier to choose the right tool for the right job compared to supporting OS-X, Linux and Windows at once just because the whole desktop and usage of OS-X and Linux or Windows is quite different. There are so tiny differences that make you cry out loud like OS-X not having a 'tray notification bar' which is available under most Linux and Windows desktops and which can be very usable for desktop applications. There is such a thing in OS-X as well (upper right corner) but it's still different.

Window management under OS-X is different. You close the main window of an app in windows and it will close the entire app (standard behaviour). You can still add that behaviour to your OS-X variant. Sure but you'll have to take all those tiny differences and make it work.

Sometimes it even makes more sense to write for each platform than to have all the hassles fixing the differences with a lot of conditionals in your code.

Under OS-X your best bet is Xcode which is on the second DVD and which is free but you'll have to learn objective-C which is quite a strange language if you are used to C or any other c-style language.

And now I'm going to tell you one big secret about me and my plans in the future and why this topic ruined many weekends trying to figure out how to develop the most generic app that runs on Windows, Linux and OS-X and I tell you what: I failed'I failed all the times and the reason is that you simply can't code that generic. It's just impossible.

I _really_ downloaded Realstudio 2010 trial because they promised cross platform development with that tool is possible and simple plus you can create binaries for Windows, Linux and OS-X under one OS (cross compiling).

I tried that and yes, you can do all that and it's really a breeze to work with realstudio and I even bought a license in the end but there is still the issue of different concepts for each operating system. Realstudio handles these quite well but at some points you still have to workaround with conditionals.

I'm still hacking perl and clojure to develop web services and all kinds of things but for cross platform gui development realstudio 2010 is really one way to go though you have to code in a basic dialect. The only drawback is the licensecosts but the prices are quite low. I bought an os-x pro license so I can test on all supported operating systems.

So what? Nothing! Just that cross platform gui development needs careful thinking before you invest time that will be wasted somewhere. Think about it before you start.

This text was written almost 7 years ago. Most of the problems still exist though with the appearance of 'electron' companies started to create cross platform gui applications with the help of web technologies. Electron is more or less a chrome webbrowser without the control elements and with added functionality.

I'm out.

I hope this text was useful.