The native platforms:
Android SDK
If you go this route, you're stuck with Java. The Android SDK for whatever reason is tied completely to the Java programming language, despite Oracle using it as a rod to try and beat Google with. The API that it provides is fairly usable and there are a large number of tools which make this quite an easy process. However, this is only if you intend to target Android devices and nothing else.Android NDK
It's curious that Google doesn't put more work into this, it seems that they try to do everything to discourage developers from using it. This is partly because applications which are developed this way will not make architecture agnostic executables. Nonetheless, the NDK has a lot of potential as a LLVM compatible compile target which could support a number of languages targeting it. However, the Google supported libraries with this are limited, it is essentially the case that you call NDK code from an SDK developed application putting limits on what you can do with it. There are some positives in that you can at least write applications using SDL, for instance, this way.iOS SDK
Again this is a similar situation as with the Android SDK. You have a couple of options here, you can choose to write applications using Apple's latest and greatest Swift language or you can choose to use Objective-C. Because Objective-C is compatible with C, it is also possible to write applications in C (just like with Android). Again, though, choosing to use the native libraries ties you to that target platform.Windows Phone
C# or something. I'm not really familiar but I assume that it's pretty good and again totally analogous with the iOS and Android situations.What you probably notice here is that all of the provider supported phone platforms have basically zero interoperability with one another.
This goes fairly deep as Google's version of Java does not rely on standard .class files full of Java Byte Code, but instead packages code into its own Dex format (which incidentally is not compatible with any platform bar Android). The consequence of this is that, while the platform is very well optimised with Java code, no other languages in the Java ecosystem are compatible with it (which rules out Clojure, Scala, JPython, JRuby, and so on).
So we've ascertained that the standard toolkits are incompatible with one another. What are we to do? Well there are a number of cross platform SDKs:
Xamarin
Xamarin is the most popular/best marketed cross platform framework for mobile development. It has the major advantage of creating applications with a "native" look and feel, but unfortunately is not free. It also has the caveat of only supporting C# and since it is a closed platform solution, it is unlikely to gain any developer support in terms of supporting other languages. It also seems to only provide a thin layer of abstraction between Android and iOS, meaning that you'll still have to write a large amount of platform dependent code unless you can shoehorn it into their forms framework.Qt
Qt has been around for a long, long time on the desktop and you can program mobile applications with it, too. Applications that you create with it will have a native look and feel, and indeed it's open source so you can use it for free. Again though, it does very little to provide developers any flexibility in terms of the tools they can use with their project and you will be using their QtQuick QML and ECMAScript/JS dialect to write your applications.
JavaScript/HTML5
There are ways to bundle your webpage into an app if you want to. Cordova is one such technology although its documentation is for whatever reason mindbogglingly obtuse to for something which you would want to use to simplify your workflow. There is also the caveat that such applications cannot resemble the native UI, and they will by necessity be running in some kind of VM which may harm battery life (although I cannot confirm this). Attempts at simplifying this include PhoneGap and Intel's XDK - even then these are not exactly seamlessLibGDX
LibGDX is a Java framework primarily for games which targets Android, iOS, the web (using GWT) and the desktop. It does what it does very well, giving a unified interface to create games for many platforms. However, it has the caveat that it is domain specific (you can see this as a strength or a weakness). It also has a user interface library which you can use to create stylised (but very non-native looking) UIs. This is a strong candidate if you're a game programmer who wants to target multiple devices.---------
While there are a plethora of solutions for creating different kinds of applications for the mobile platform, some of them even interoperable with desktops, it's striking that there's also no highly unified, open way of creating mobile applications which allows you to use your own tooling, your own choice of language - essentially what I'm trying to get at here is that while there are several highly targeted platforms for mobile development, they are all quite tied down by their limitations. This is not the same on the desktop where you can have a new language, for instance Nim, which can be made compatible with all of your existing libraries through foreign function interfaces or you can develop native-look applications with any of a multitude of free libraries which have wrappers for a vast amount of programming languages.
Even Java, the venerable advocate of portability, has been torn apart by this situation where under Android its implementation is highly non-standard, its implementation is far behind the language specification (Java 8's first stable release was in March 2014 and is still not supported even though it is the platform's major language; the JEPs for the language dating as far back as 2011) and its ecosystem is barely supported at all (with the notable exception of its IDEs). Nobody seems to be attempting to write backends for other major programming languages which target the Android Dex bytecode format. There is, for instance, no Dex backend for LLVM (at least not that I can find).
It's hard to tell what the future holds - I imagine that in the distant future it might turn out that WebAssembly is used as a standard target running in a small VM on phones. Ultimately it would be good if the companies involved could band together and attempt to standardise the situation somehow but of course they have vested interests in trying to make developers focus on one platform or the other. It's important to remember that the reason this happened on the desktop is because the x86 architecture became dominant and everybody just targeted that. In this brave new world of hardware agnostic phone OS vendors that is no longer possible. Of course it's a good thing that hardware vendors can be competitive in the mobile devices industry, but the fact that the abstractions don't play nice together is problematic.
It is worrying that the major player with regards to cross-platform compatibility seems to be Xamarin with their closed, pricey, solution that still requires you to write a lot of device dependent code. Frustratingly it seems that the best solutions at the moment are either to write your application n many times for the platforms you wish to target or use the web as a target since that is also supported everywhere - Qt probably offers the best trade off between these solutions as it stands and LibGDX is great if you're interested in implementing a game.
