Creating Cylix for Windows, Mac OS and Linux has been a challenging task, as building any cross platform software is going to be. Between Cylix 1.0.0 BETA and Cylix 1.0.0 MacOS, Linux & Windows, we had some trouble because the Apple Developer Certificate had an issue on the MacOS version. This certificate is what gives us the pass to make our application convenient to use on MacOS devices, but the software wouldn’t start in Beta.
We wanted to add support for Linux without being exclusive, so we made sure that users would be able to run the application on all four main distros of Linux. There were initial issues with the Windows version as well, all of which kept our team on its toes before the official release.
But even when you’re working with a powerful language like C++, which has compilers for every platform, there are challenges in building cross platform software.
The aches and pains of cross platform software development
When we envisioned Cylix, we wanted everyone to be able to use it, irrespective of what platform they were on. But we didn’t want to have to write the code out three times.
What is fantastic about C++ is that it has some powerful open-source compilers. There are also some proprietary compilers that range from some of the biggest supercomputers to embedded systems. We have stopped at the QT framework and SDK, have fallen in-love and never looked back since.
Now, you can write C++ in a portable way, but there are language extensions, toolkits, and APIs that are unique to each platform. Not all libraries, versions and features can be implemented in every compiler. In other words, not all these features and libraries are available for all platforms. So, the binaries that developers create for Windows, for example, may only sometimes be interchangeable with binaries produced by the application in MacOS. But binaries are mostly not portable between the platforms.
So, when writing code for a software like Cylix that would run on multiple platforms, we must take care to stay away from code that is platform-specific and compiler-specific. For instance, if you want to compile a code on Linux or Mac, using Microsoft’s COM (Component Object Model) won’t be useful. We have aimed for the golden egg of software development: one code base to rule them all. We have shot ourselves in the foot multiple times, struggled, clenched our teeth, but did not stop until issues got resolved. Moving forward to iOS and Android should be fun.
Additionally, all third party libraries that we used had to be documented so that they would support the right targets. A compiler available for each platform doesn’t mean that you can directly port the code and hit compile to be able to run the program on another platform.
Another issue that crops up when you’re dealing with cross platform software is in the area of automated building and testing. Many developers find this to be the most difficult part of the process. Amongst things to disappoint are problems like builds not compiling, problems with the packaging system, libraries not being loaded, relative paths to project libraries, which are also platform libraries not being updated and much more. They will show over and over again until platform and processes become stable enough and you feel like a character coming out of True Grit.
While developing Cylix to be a cross platform software, we faced these and other challenges. It was important to be able to see changes that we made on one platform, in the other versions within a short period. Our advice to anyone who embarks on such projects is to ensure that their cross platform software project considers both the challenges and rewards of cross platform development integrate it into their workflow and most of all choose wisely.