Can you have a single application that works on all platforms? Yes, you can. There are a number of ways to do that. But should you?
The Case For Single Code Base
Development is expensive. So writing things once and being able to reuse them regardless of the platform seems to be a logical choice. Take for example websites. Once developers implemented things like “mobile first” and “graceful degradation” it became somewhat common to have just one set of code for a website. There are still some kinks to work out, but for the simple stuff, it works fairly well.
Fortunately for most web developers, libraries exist that make the typical problems of platform differences manageable. But like everything, there are trade offs.
The same exists for applications that are not browser based. Libraries exist to hide the differences. You can write once and deploy anywhere. Java Applets were the first that I know of that advertised such a thing (excluding languages such as Java itself, but I’ll get to that in a second). And while it did “work” for some things, it was not a smooth process. There are not too many Java Applets still in active development. I doubt any new projects are choosing it.
Qt is another that attempts to hide the differences. And while it could be argued that they have achieved more than what Java Applets promised, and there are many applications (even new ones) choosing to use it, the question remains. Should you aim for a single code base?
The Case Against a Single Code Base
If you plan to build a large application and support a variety of platforms, the idea of a single code base is very tempting. But in more than a few cases, those that began down that path regretted their decision. Some have opted to rewrite. And of those that chose to rewrite, I would venture to say the majority adopted to manage multiple code bases rather than taking on another single code base framework.
We will back up a step and talk about some common obstacles projects run into.
Operating systems have different ways of handling multi threading. Hardware platforms have different ways of handling user input. Two very basic subsystems that may affect the way you write your application. The holy grail is that the framework you chose knows how you want to handle such differences and simply does the right thing. That is often not the case.
Add to that, having your code go through layers of decisions to figure out how to handle such decisions during runtime (I’m talking about you, scripting languages) means you are using the high-tech horsepower (not to mention battery) in your user’s mobile device on making those decisions rather than concentrating on giving them the information they are digging for.
The Takeaway
No one can say that writing a single code base for multiple platforms is always a bad idea. It will very much depend on what you are trying to build. But such a fundamental decision, which must be made very early in the development process, should be made with care.
Is there a way to architect the application to share some code? Many applications write the UI in the language of the platform, and the hard-core business logic in another language that can be shared across platforms. Is it ideal? No. But it sometimes works as an advantage.
A Real World Example
I built an application that required a client application to receive data from a stock exchange. The data needed to be up-to-date, and accessible on a desktop, in a mobile application (Android and iOS), and via a web browser. For the desktop version, the desire was to give it a large quantity of information and allow it to do advanced analytics. For the mobile version, more basic data was to be sent, considering often lower bandwidth and a desire to conserve battery. For the website and web server, it was a mix. The website would have basic information, but provide APIs to get more data. Very little analytics would be done on the server side.
Is there any way to write such things in one framework? Yes. Several in fact. I could do it all in something like React and NodeJS. I could also throw all frameworks away and write it all in straight C++. Those are bad ideas.
In this case, there were multiple frameworks and languages used. For the uninitiated, diagrams looked like a bunch of squares and circles with lines going everywhere. But in reality, the best technical choices were made for each requirement. The result was an extremely performant and maintainable system, constructed in multiple languages, that worked reliably together. Android and iOS applications, while sharing a lot of their structure, shared none of the code.
Did such a project waste developer effort? Far from it. And as for ongoing maintenance, I believe the effort will be less than if the use of a single framework was attempted.