Cross-Platform Apps – Best Practices for Web and Mobile Development

Yes, in general, the .NET Framework is great for apps that target a broad range of devices. But this isn't unique to .NET; Java was doing that long before. The thing to keep in mind is that there's no real alternative to the native tools for a particular platform.

The Mac applications that you create with .NET will never look like native Mac OS X applications, and that's considered a problem by the vast majority of OS X users. That may not be important to you strategically, depending on whether your business model values maximizing saturation over maximizing user satisfaction, but it's certainly something to keep in mind when making a choice.

The GUI systems in Linux and Windows are somewhat more flexible in terms of which applications look "native" and fit in well with the platform. But I blame that mainly on the lack of clear interface guidelines and the fact that application developers have historically been willing to ignore the ones that do exist. Many Mac users prefer the Mac precisely because of its consistent user interface.

Considering that you'll have to adapt the GUI layer to the specific platform (and possibly rewrite it in a different language entirely, such as Objective-C), that leaves you leveraging the .NET platform only for library code. And then there's not a very clear win for C# over C++, in my opinion.

For rapid application development, there are few alternatives that are better than C# and .NET. And pushing an app out quickly and having it immediately available on a diversity of platforms is certainly a business advantage. But for true multi-platform applications that aim to truly satisfy the user, it's not necessarily the silver bullet solution.

There is a very clear line in the sand between cross-platform and mono-platform:

Does a program use only those APIs exposed by the Standard Library it is built on?

If you target a standard implementation, then any platform that implements that standard should, in theory, compile and run your program correctly. There are plenty of exceptions, but in general if you avoid clever tricks you should be able to avoid many of those exceptions.

The reason why this issue comes up specifically with C++ is that for the longest time the C++ Standard Library did not include many modules that are useful for non-trivial programs. Concurrency and GUI are the two big ones. This meant that a program built using only the C++ Standard Library could not have many of the features we expect from modern software.

How do we write cross-platform software that does stuff the Standard Library does not support?

You mention "cross platform libraries," which in practice are normally called "frameworks" or "toolkits" based on their scope. The way to write software in C++ that is cross-platform is to target not only the Standard Library, but a framework that builds on your target platforms.

Essentially, you end up externalizing the platform-specific bits to another library. For example, wxWidgets is a popular framework. You can use its classes to construct a GUI and related functionality (e.g. standard dialogs for selecting files). Under the covers, it uses conditional compiling to implement the GUI using the native GUI for each platform. But as the user of the library, none of that matters to you.

Historical note: here in 2015 C++ compilers and libraries are, for the most part, really good. Go back a few years, and that is not true. C++ did not have an official standard until 1998, many years after its inception. It took vendors a long time to update their compilers and libraries to implement the standard correctly. Vendor-specific extensions abounded (and are still around, actually). Some compilers had nonstandard headers and functionality. Code portability was virtually nonexistent. C++'s reputation in terms of portability still suffers.