Windows cross-platform client software is hard to do
Since the days of MS-DOS versus CP/M, developers have been motivated to write client applications that work in any user environment and take advantage of each operating system's unique features. This has always been a hard problem. But, unlike other programming challenges, it hasn’t gotten much easier over time. Microsoft's approach of "Windows 10 on everything" suggests that the Universal Windows Platform is its answer. Whether it meets the needs of your IT shop is another matter.
Code portability across server platforms is not as much of an issue as it used to be. The frameworks developers use very often run on both Linux and Windows, using languages such as Java and Python, which also run on both environments. Even if you’re interacting with a system that is native to Windows, such as Microsoft Exchange, often an API or some similar mechanism can help you write portable software.
That is not so with client programs. The tools and methodology for writing native software for Windows, Android, iOS, and Macintosh are very different. While many portability techniques for server programs work for client software as well, they aren't suited to optimized user interfaces. Windows and Mac are powerful, general-purpose computing platforms that give developers a lot of freedom. Developers want to take advantage of that power, and end users appreciate programs with better user interfaces.
Tools, APIs, and frameworks
There have always been simple, unsatisfying user interface methods for those who want to write a program that runs across platforms with little or no modification. The command line is the most basic. And there have been many attempts at developer frameworks to map GUI systems (Windows, Mac, and Unix/Linux versions), which can provide programs that are functional, if unspectacular.
But when the iPhone came along, things changed radically. Now there was a platform developers wanted to target and for which the development language (Objective-C) and SDK were not the ones most commonly used. (Of course, Mac developers may have known Objective-C, but it’s never had a major presence in enterprise development.) Android added another language (Java) and an SDK that probably bore no relation to whatever business developers were using to write client-side software.
Given all this, enterprise developers get interested when they see tools, APIs, and frameworks for building software that works across multiple operating systems. Whether you can make really top-notch, native-looking programs on all platforms is a matter that gets people arguing loudly.
Here's a roundup of some of the options. My own preference is basically “none of the above.”
Universal Windows Platform
Microsoft has two major cross-platform solutions, neither of which covers all the bases.
Universal Windows Platform (UWP) is basically about games, but there’s a bit more to it. UWP is an API for building programs that run on all Windows platforms. “All” doesn’t really mean all, at least for now. The supported environments start with Windows 10 and includes Windows 10 Mobile, Windows 10 IoT, Xbox One, Windows Mixed Reality, and Xbox One X. (Windows 10 Mobile is the effectively dead Windows Phone. I don’t mean to disparage it; I loved it. But the ability to write software for it is no longer of much value.)
Note that neither Windows 7 nor Windows 8 are on that list of supported environments. Windows 8 may not be much of an issue, but you probably still have Windows 7 users, so you can’t target them with UWP. On the other hand, and this is a stronger argument, all Windows 7 support ends in January 2020, so your only planning for it should be for replacing it with Windows 10, which is a much better product anyway.
Consider also that UWP apps are meant to be distributed through a store, generally the Microsoft Store, although Microsoft offers an enterprise store option and it is possible to side-load apps.
Xamarin is based on a portable implementation of the .NET framework called Mono, and it is a much more credible option for cross-platform development. The company that built it was purchased by Microsoft in 2016.
Xamarin’s tools, based around Microsoft Visual Studio, are some of the best for building programs to run on iOS and Android, as well as on Windows and macOS. Applications for Xamarin can be written in C# and F#. Not everything is portable across all of the platforms, and you still need to deal with platform specifics. But Xamarin does allow developers to make a common code base for things like business logic, local data access, and web services.
For user interface-specific code, you at least need to be aware of how the code will appear on each platform. You likely need a Mac if you want to write Mac or iOS code. This Microsoft video says a lot about how the development process works, and the company has a collection of sample apps written with Xamarin.
Java is the granddaddy of cross-platform development, but in the mobile world, its role has not had much to do with portability. Native Android applications are written in Java, but that doesn’t get them to run on any other platforms.
JavaFX, which became part of the standard Java Development Kit (JDK) and Java Runtime Environment (JRE) with version 8 of those systems, is the best attempt at making user-facing, cross-platform Java programs. That gets you Windows, Mac, and anywhere else the Java VM runs, though ironically, not including Android. To get to mobile devices, you need to use third-party projects that fill in the gaps, such as JavaFXPorts and other tools from Gluon.
Remember that distributing client-side Java applications means your client systems need to have Java installed and be kept up to date. It used to be the case that Java was installed everywhere, but long and unpleasant succession of security problems made it anathema to many.
In the real world…
If cross-platform support is really important for your client-facing software, the only practical choice is probably the web browser. It’s the only platform for application development that has a universally compatible language and, through Cascading Style Sheets, can adjust to the specific device on which it runs.
The history of the web browser as a development target was one of compromise. Web browsers were slow, the user interface was limited in features, and you had to deal with incompatibilities between browsers. The major browser developers, led by Google, have been adopting standards for highly capable web-based software called progressive web apps (PWAs), which I wrote about previously. As with everything else, PWA adoption is taking far longer than it should.
The limitations of the browser also underscore the waste of client resources. Yes, it’s a good thing that web design lets you offload heavy computation to the server end, but the average PC has a lot of computational power that often is left unused. In many ways, this validates the use of VDI or the Chromebook model for client deployment.
Many developers argue—persuasively, in theory—that you get the best performance by writing native code for the platform on which the software will run. This is not only true, it’s a tautology. It just doesn’t matter much anymore. Software doesn’t have to be as fast as it can be—especially client-facing software. It just needs to be fast enough. Why especially client-facing software? Because software running on the server competes for resources with many other processes. On the client, it likely has a wealth of underutilized processing power.
Not every client-facing application is best written for a web browser, but most of them are. Have you looked at Microsoft Office 365 or Google G Suite lately? If you really need to do more than that, the best solution depends a lot on what you’re already familiar with. Just don’t dismiss the browser out of hand, because it’s all headed there anyway.
Cross-platform development: Lessons for leaders
- Determine if the application requires client resources first.
- Don't forget security.
- If cross-platform delivery is a requirement, the mantra should be "web first."
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.