Why is there software that doesn't support certain platforms? [closed]

Question

I noticed a huge portion of software apps only support Windows and not Mac or Linux. I understand that there might be an API that they're using that only exists on a certain system. In this case, why don't programmers use cross-platform APIs instead, that have portable frontends that interact with non-portable backends? Are there any benefits to using non-portable APIs over portable ones?

Answer 1

There is some gross missunderstanding about APIs here.

Platform-specific APIs are the norm, with platform-independent APIs being the exception. At least historically.

As a developer, if you want to make a platform-independent application, you have to reimplement significant portion of your application, or even the full application, for each platform, because the APIs are fundamentally different. Basic memory work, IO manipulation, processes, threading, all of these behave fundamentally differently on different platforms and systems. And your application needs to adapt to that.

Feature-full cross-plaform APIs are a relatively new phenomenon, especially for specific types of applications. Creating a cross-platform console application or web application has been possible for a while. This was because despite APIs being different, there were ways to abstract them away, along with proper platform adapters. There was less focus on cross-platform UI applications, because most UI frameworks are both complex and different enough, that creating a common API is both time-consuming and creates issues with platform-specific features missing.

Answer 2

One major component mentioned in the comments on your question is cost/benefit. Developing a cross-platform application or API is more expensive up-front than a single-platform piece of software. Every API or library has, at least, slightly different behaviour on different platforms, or very different behaviour, or there's not one single library for all platforms and you have to mix/match with an adapter in between. The operating system has different rules about where files go and what access there is. The drivers for hardware that you are using have slightly different behaviour. Users of the different platforms have different expectations.
For example - Linux users will tend to expect their software to be open-source or will be unlikely to adopt.
Apple users expect a certain level of UI/UX experience that has to keep up with the current desktop paradigms that may shift.
Phones and tablets have much less display space and usually limited resources...

In addition, validation and testing of a multiplatform solution is expensive. You'll need access to a lot of VMs and/or hardware, and each platform takes about as much testing time as all the others.

So if a company makes the vast majority of their revenue on the most common platform then investing in the others may not be worth it from a cost/benefit perspective. I have worked on closed-source, specialized cross-platform libraries, and the team did a great job creating a codebase that could be used with equivalent functionality across Windows, OS-X and iOS (with some tentative Linux builds too). However, in the end there was no real revenue from any of the platforms besides Windows, so maintenance of the other platforms petered out.

Answer 3

There are two major impediments:

1. Lack of standardization between platforms
2. The need for "write once test everywhere" even when using cross-operating system languages like Java or C/C++.

For instance, HTML and JavaScript are very much standardized, and you can write a web application on an operating system that will be accessed transparently from multiple user operating systems. Before I retired I worked in such an environment developing (in Java/J2EE) on Windows and deploying on Linux. This was just about hassle free. Compatibility problems had more to do with browser quirks than problems with the underlying user operating systems.

But consider developing a GUI application on Windows and expecting it to work on Windows, Linux, MacOS, Android and IOS. Quite simply you are up for a huge amount of testing, and will need a number of hardware platforms to test on. Google, Microsoft and Apple have little interest in making compatible systems. There are frameworks like GTK that help, but you will still be up for a lot of testing time, and the result often does not feel "native" to the platform.

Also, there are good reasons for developing differently for different platforms. For instance, in the past web applications often had tens of fields on a form. This works great on a big monitor, but is close to unusable on the small screens of phones. Similarly the availability (or not) of touch-screen features can mean an application needs lots of user friendliness testing before release.

There are some bright spots. Frameworks like Cordova, React, Flutter etc ease the task of building Android/Mobile/Web applications, and this is a hot area of development.

Answer 4

Building an application is the same as playing Tetris with weird shaped pieces. Every piece must fit perfectly together for it to work.

The simplest example is some hardware with an application running on it. For this to work, the interface between the hardware and application must match.

In reality this is a cumbersome process. Who wants to control all details of the hardware on their own? If you embark on this journey you are either never going to get done, or you have a very niche usage on some very specific hardware.

Therefore, we use a standard program to manage all the hardware for us - an Operating System. This ensures the interface between the hardware and the application. But as can be seen, now the application must conform to the interface of the Operating System. A lot easier, but still a requirement.

Why can't I just run the application on all Operating Systems you ask. Well, the interface of the Operating Systems are not the same for a number of (very good) reasons.

This means that if you want your application to run of two different Operating Systems you must build your application twice. Three times for three Operating Systems. You get the idea.

Someone else identified this issue and tried to solve it. An example of this is Unity. They have made a number of different versions which can run on different Operating Systems. Suddenly, your application no longer needs to worry about which OS is underneath. However, now you've tied yourself to Unity. Is this better? Depends on your scenario.

Of course, not everyone wants to use Unity (or some similar solution). So they either have to have one version for each Operating System or simply choose only to support a few select of them.

There are of course a multitude of variations of this - not all hardware is the same, there can be several additional layers and so forth.

(I've tried a more visual approach here with fewer technical details, so perhaps some parts are more easily understood by those with no technical insight into this.)

Answer 5

As others well-pointed, in the end, the decision comes down to a convenience and cost/benefit problem.

For example, in the mobile development sector, cross-platform implementations are a real thing. In my experience working for a consultancy specialized in that field, I can say that for many customers the first option is a cross-platform solution and the reason is obvious: costs.

Developing 2 native apps is not only more expensive, some times it's not worth it due to the market segmentation. If the segmentation is decompensated, a cross-platform application is reasonable. When costs are not a reason, the law can be. For instance, public organizations want to reach all citizens regardless of individual platforms.

Are there any benefits to using non-portable APIs over portable ones?

In line with the previous arguments, cross-platform apps suffer from interoperability constraints with the underlying platform.

Platforms and cross-platform frameworks/API evolves at different paces. Platforms change first, and after a while cross-platform frameworks adopt these changes, but not always successfully or in time which causes losses due to the opportunity cost.

Feature missing (sometimes) forces developers to implement walkarounds that rarely make for a good UX; it's also considered boiled plate code which is not always portable to newer versions of the cross-platform framework.

Answer 6

Even cross-platform languages such as, say, Mono tend to behave slightly differently on different platforms.

In this example, between Linux, Windows and Android the user interfaces render slightly differently, especially for UIs built using a Winforms designer, so they require some tweaking before they're entirely satisfactory.

(And in this specific example, I doubt that Mono has had enough use on the Mac or the M1 to be quite free of defects.)

Moreover, differences in display geometry and user-interaction services, e.g. small vs. large screen, mouse vs. touchscreen, presence or absence of a physical keyboard, dictate different design decisions.

So while it's easier than it was fifteen years ago, to write for multiple platforms still isn't merely a design choice; it entails some effort.

Answer 7

Because an API is only a way to say what you want done. If what you want is not possible on the platform, it is pointless implementing the API as it would merely report that your command failed. Sometimes the underlying behaviour is just different.

For example, on Linux, you can delete a file while it is open and the program which has it open can keep using the file until it closes it. During this period, the file does not have a name. On Windows, you can't delete a file that is open. However, the capability to use a deleted file is exploited on Linux by programs that need a temporary file that will be guaranteed to go away even if the program, or thw whole operating system, crashes. This ability is used when updating software, which is why Windows needs to reboot after so many updates, but Linux does not. Windows has a mechanism whereby a file can be deleted at the next reboot, so updates have to use this for files that are in use rather than simply replacing them.

And some differences may affect user interactions. On Linux, if you use a windowing system derived from X11 (which you almost certainly do), there are two different types of copy and paste. I can highlight text with the mouse, and them middle click elsewhere and the text is copied - no need to hit ctrl-C or choose a "Copy" menu command. This uses the "primary selection". But there is also a copy and paste just like Windows - highlight text, hit ctrl-C, click elsewhere, hit ctrl-V. This is called the "clipboard". The two mechanisms are separate, so after copying one thing with ctrl-C, I can copy another by highlighting and paste whichever I like. In fact there's also a secondary selection, but I have never felt the need to use it.

To give an analogy, an API is like a language. But however well a New Yorker learns French, they won't see the Eiffel Tower in New York. They could climb the Statue of Liberty instead, but that would still be a different experience.

Answer 8

There already many answers and many good reasons for the situation. But there is a point that is missing. Developers training and IDEs and tool that make too easy to include libraries and functions that then lock the final result to an OS.

IDEs that generated part of the code started at the end of the '90 with Borland. But Borland quickly succumbed to Microsoft Visual Studio and with it came the practice of using tools that made things easy, but at the same time included vendor lock ins.

After that the problem involved the frameworks whose role in the applications became increasingly important. Some frameworks encourage platform independence some do the opposite. The initial choice will have consequences on the final product. But the initial choice often depends on the skills and the training of the developers involved.

There is no free lunch. When it is too easy and too quick to develop an application there is going to be a downside somewhere. Some king of vendor lock in is often one of those downsides.