AFAIK there's nothing stopping you using Kotlin on iOS with RoboVM since it is a JVM language - https://robovm.com.

True enough, but I really don't like depending on closed source solutions for something so fundamental as getting my code to run on a platform. I feel like I am betting the future of the product on the future of this company. Of course, I am already betting on the future of iOS and Android, but I have a lot more confidence on those too than on RoboVM

On top of that, RoboVM uses its own LLVM-based compiler rather than Apple's. So if Apple throws us a new compilation requirement, similar to the requirement to provide bitcode for watchOS and tvOS, then we're stuck until RoboVM is updated. With j2objc, you're using Apple's compiler to produce the machine code.

Could you develop libraries that way, though? It would have to be absolutely pure Swift, not using any iOS libraries, like NSURL etc. etc. - surely incredibly limiting.

Not true. Both Foundation and Core Foundation libraries will be eventually ported and open sourced.

This feels a little like wishful thinking. Remember YellowBox back when Apple originally bought NeXT?

YellowBox was going to be a cross-platform updated version of the OpenStep APIs. While I remember some alphas of it, it basically got nixed.

http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7...

As much as I enjoy using Apple products, their history says that they would not directly support something like this.

We are long long days since that.

https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch

Works is well under way.

Omg, I had no idea. Awesome!

Absolutely I could. In fact, as I said, I already am, albeit with a more limited technology. For building multiplatform apps I build all the business logic in a Java library which I then convert to iOS using J2Objc. IME this is always between a third and half of the code that is now shared between platforms. For classes that will depend on platform specific stuff, like newtork requests that are handled differently by iOS and Android I use interfaces that I later implement (as protocols) on each side. iOS does end up feeling as a second class citizen though, because J2Obj is not exactly fast; if I need a change in the library, a recompile can take a few minutes

You could this for your own libraries, but I would strongly recommend against doing this for a public lib if you want traction (e.g. if you are making a bunch of SDKs for your APIs) - in this case you should publish your lib in the most popular language(s) for the platform(s) you are targeting.

>but being able to develop libraries in one language and use them in both Android and iOS is huge

I have no doubt that there are mobile only apps that would find this valuable - but swift is still only linux/android and osx/ios - if you want truly portable code - that can compile to browser/mobile/server/desktop you're stuck with C++ for the foreseeable future.

I've tried Haxe, Racket, TCL/tk, MOAI (Lua based), and others, but I am now using 8th, a Forth-like language that compiles to Android, iOS, Windows, OSX and Linux [1]. The only downside is that I still need a Mac to publish iOS apps. For Android, Windows and Linux, I am good to go. It uses the JUCE library for gui implementation. I have made two toy apps for Android so far, and I am still learning. It has a good library so far, but some people find Forth difficult. I find it concise, expressive and still readable after 6 months. The shortness makes code review a breeze.

  [1] http://8th-dev.com/

What a strange beast! A closed source language is always a tricky sell. Forth is never an easy sell in itself (unless you've already been bitten by the bug ;-) in which case it's a wonderful bonus). The tutorial is PDF only - which just seems a bit odd.

I'm intrigued by 8th - in a good way - and happy you've introduced me to it - but I do wonder what kind of uptake something like this will get.

It is a bit odd, but I am rocking with it. I have done Java and NDK in C++ tutorials to get simple programs running, but nothing original, or beyond what the tutorial provided. With 8th, I can whip up something quick with a GUI, using the sensors and other libs it comes with, and deploy it. It looks the same on Windows, Android and Linux. The developer makes him self available, and quite honestly, the code is succinct enough and the documentation good enough that I only asked a lot the first week. You should give it a try. I am by no means a 'Forth programmer', and 8th is not a compliant Forth.

How so? Doesn't this port to Android show that a Windows port is surely possible? Swift is already running on servers afaik. As for compiling to "browser," Swift is based on LLVM so should be just as capable of this as C++.

What's "possible" and what's available and tested in production right now are two very different things. These kinds of ports take at least a year to get over the initial troubles and become usable and then you're at least that time away from a decent size of community libraries to spring up for the mentioned platforms.

By that time Rust will also mature enough and webasm will land so Rust will probably be a better candidate (since it's OSS and developed by a browser company that needs to run on as many platforms as possible they have much better incentives to maintain ports than Apple).

Also in that time C++ will probably get modules working on clang and many c++17 features.

And you might see Xamarin merge into CoreCLR and rolled up into VS integration.

A lot of things are possible - but what's available right now is C++ on every platform and not much else.

What's the canonical way of targeting Android with C++?

Write shared logic in C++ and use JNI/JNA ? Or are you asking about something more specific ?

I guess I found what I was asking about, i.e. NDK: http://developer.android.com/ndk/index.html

I'm not sure about how mainstream/supported C++ is in the Android world.

Just as much as everywhere else, we're using it extensively for sharing code. If has a few qurks but it's easy better than windows for example.

Are you using NDK? I was reading about it earlier, it is something that I would like to look into, when I have some time.

Yes, NDK is after all just a name for preconfigured GCC and Clang package shipped by Google :)

We use Clang 3.5.

Yeah for an example of what I would love to be able to use on both android and ios : http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios...