By Daniel McDonald
Python Developer

One of the most important requirements for software companies is that the software they produce runs on their (potential) users’ hardware. This assumption is so fundamental, it’s easy to forget it’s even a consideration. But on the technical side, it’s a huge consideration. Any company trying to support most people will spend the time to make software for Microsoft Windows, but nobody these days supports a TRS-80 Model II because each supported platform is an investment, and it’s rarely worth the trade-off to support a rarely used computer. At CX, we make our cloud storage products useful and attractive across several platforms for as many customers as we can.

Here’s an example of what happens when you don’t bother to make an app pretty for OS X:

This image induces nausea in many OS X users because it is jarringly incongruent with the rest of their software. However, the developers were able to write a single user interface (using the Tcl/Tk platform) and run it on OS X, Windows, Linux and other platforms. So while it may not score any points for aesthetics, it is functional and works in many places. And now for a counter example, here is an app made to look good on O SX:

This application looks clean, professional and consistent with the rest of OS X. However, all of the work they put into making this look good doesn’t get them anywhere on having a user interface for Windows or any other platform.

With CX’s desktop sync app, we take a hybrid approach. We use Python code to drive the file syncing logic that is common on all platforms so that we only have to write this code once. Then we try to pick the best option to have a good, natural-looking user interface on each of our supported platforms. We use .NET on Windows and Cocoa on OS X. This approach has definitely succeeded in producing two native-looking applications while tapping into the powerful common Python syncing logic.

However, this approach has demonstrated its drawbacks. Every time we add a new feature that involves the user interface in any way, we have to duplicate our efforts in changing the user interface changes for the Windows and Mac platforms. Adding support for another platform (for example, Linux) means writing a new user interface from scratch that has all the features of the other two platforms, and every additional change to the user interface requires us to duplicate our efforts over three platforms!

This is why for our Zipline product, we swung back to the other side and chose to use the QT platform. QT lets us rapidly develop very attractive applications with a single code base:

QT isn’t a silver bullet. We still lose a little bit of the native feel, but with good styling and design, we can produce an app that’s still aesthetically pleasing and intuitive to use, and we’re really happy with the results. We expect this will improve our ability to deliver new features to our desktop software users more quickly and possibly make adding support for additional platforms possible.

Do you have any thoughts about cross-platform development you’d like to share? Let us know what they are in the comments.