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?

  • 17
    Typically you develop software for the platform your users are on. If your users are only on platform X, why bother with other platforms?
    – Rik D
    Jun 12, 2023 at 4:01
  • 15
    Apple and Microsoft were not really interested in crossplatform applications in the past, applications only available for Windows or iOS help them to sell more licenses of their OS or their hardware. This has changed somewhat over the last few years by demands of the market and a shift in where those companies gain their most revenue.
    – Doc Brown
    Jun 12, 2023 at 5:38
  • 38
    In my experience, there is no such thing as a true cross platform API except for some very basic things that are possible because hardware essentially works the same way. Even the standard C library might work differently in some edge cases on different platforms. Cross platform APIs are hard to make, hard to use.
    – Ccm
    Jun 12, 2023 at 6:06
  • 9
    Especially with regard to GUI frameworks, you have two options: "native" (different on every platform), or "crossplatform" (same on every platform .. but looks different from all the native apps!). These are inherently in tension. Currently there seems to be a convergence on Electron style desktop web apps.
    – pjc50
    Jun 12, 2023 at 9:56
  • 6
    Why would a novelist write a book in English and not in every other language as well? There's even "APIs" (e.g. Google Translate) that can translate that novel into a bunch of other languages. Will it be a perfect translation? No, in fact, it will probably be terrible, unless you have human editors fluent in both English and the target language for every language you want to publish in. It's the same thing with software. Making something compatible with every platform takes a lot more work, even with cross platform APIs (which most are not). Jun 12, 2023 at 19:38

8 Answers 8


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.

  • 3
    There is no such thing as cross-platform APIs; there are only platforms that run on other platforms. When you make an app with Java you are not making a cross-platform app; you are making a Java app. And the Java APIs are not cross-platform, e.g. they don't work in Electron or .NET. But there are Java emulators for Windows, Mac and Linux, which are the platforms you actually care about.
    – user253751
    Jun 12, 2023 at 13:28
  • 16
    @user253751 That is kind of pedantic. In this case, the implication was that "platform" means different HW+OS . And that multi-platform means application that can run across different HW (desktop, mobile) and OS (Windows, Linux, Mac, Android) either from single binary or compiled from single source.
    – Euphoric
    Jun 12, 2023 at 13:42
  • 3
    It's worth understanding that being cross platform isn't simply a choice. It's work. It's work to the point of needing to argue that you have the right to use an open source API in front of the US Supreme Court. It's never just using the right tools. Jun 12, 2023 at 15:49
  • 1
    @user253751 Would you consider Qt a platform? It allows cross platform native apps. Also Wine Is NOT an Emulator; Wine on its own can only run binaries on the same hardware they were compiled for.
    – jaxad0127
    Jun 12, 2023 at 18:48
  • 2
    @user253751 There are not cross-platform ABIs (except there kind of are in some cases, such as the old IBCS ABI), but there very much are cross-platform APIs. POSIX is probably the most famous example (no sane person would argue that macOS, AIX, HP-UX, z/OS, and VxWorks are the same platform, but they all provide the standard POSIX API). Jun 12, 2023 at 20:54

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.

  • 1
    A good example of a technical platform difference is that on Android, if you want your app to run constantly in the background (as opposed to waking up every now and then) you must display a notification in the notification bar that says so. Otherwise it will randomly stop your app running.
    – user253751
    Jun 12, 2023 at 15:19
  • 5
    When talking about cost, you can't forget about testing. You generally support multiple version of each OS, plus with Linux you have different distros and alternative architectures (like ARM or RISC). Your QA workload will very quickly explode to 10x what it was for a single platform, which in turn costs you both time and money.
    – bta
    Jun 12, 2023 at 18:50
  • 1
    In addition to testing, there are deployment costs: can't write iOS apps without owning a Mac and paying a subscription, for example.
    – pjc50
    Jun 13, 2023 at 8:44
  • 1
    @JorisTimmermans I'm not saying it is easy or cheap, but when it's done with intent it's impressive. It's also probably helped by the fact that the company who did it is also the most responsive commercial software company that I've encountered. I once went from reporting a bug to having a patch in 2 hours - and I don't even have a support contract with them.
    – Peter M
    Jun 13, 2023 at 12:47
  • 1
    @JorisTimmermans They also have 100% training/documentation online for free, and you can download and run the complete product for free. It just runs for 2 hours when unlicensed, and you can restart as many times as you want. OTOH they are stuck with Python 2.7 as their scripting language (actually Jython) /s
    – Peter M
    Jun 13, 2023 at 13:07

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.


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.

Hardware and application

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.

Hardware and OS

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.

Different OS

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.

Different OS and you

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.)

  • this is straight forward, even caveman understand. programs are about preparing for possibilities. we pay overhead to place an if statement. if you know what to expect you can optimize. writing code is the fun part but a lot of dev is linking pieces together and telling them to be friends.
    – Dor1000
    Jun 13, 2023 at 1:33

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.

  • 3
    From my experience (Xamarin and React Native) while it's easy to create a basic IOS+Android app, for anything complex, getting it to the high level of polish our customers expected on both platforms has ALWAYS turned out to take 2X more work than writing 2 separate apps, due to all the edge cases from differences and the amount of time it took to fix those bugs. We finally bit the bullet and refactored to native apps and the bug rate went down like 5X. On the back-end it's different, Node.js works fine wherever.
    – Eugene
    Jun 12, 2023 at 17:19
  • 3
    We usually recommend native when the app is clearly in the center of the business or the app is the real product. It's not the case for public orgs or small clients, but when the UX is key, we never implement hybrid or cross-platform apps
    – Laiv
    Jun 12, 2023 at 18:06

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.


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.

  • Except the highlight and middle click copy/paste is a left-over from the console only days and framebuffer days, not X11.
    – ivanivan
    Jun 12, 2023 at 18:40
  • @ivanivan irrelevant where it comes from, it's there and it limits X in serious ways.
    – jwenting
    Jun 13, 2023 at 8:23

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.