On our last project, the Android code was of much worse quality than the iOS one (perhaps due to both tooling and Java null pointers; which can be attributed to poor development skills), so the projects did not match in terms of quality and sometimes even the way features behaved.
As of late, the spit and polish for React Native on Android has been getting better, with some features even being exclusive to Android here and there. Though personally I am super interested in Fabric, if they really do make native calls as easy and performant as they say they will it will make RN dramatically closer to native platform development.
So the idea would be you program your app’s individual screens, throw in some styling, select platform appropriate nav schemes (hamburger for android and tabbed for iOS for example) and hit compile to generate native per-platform project files+code.
This sort of solution wouldn’t cover more complicated navigation schemes or use cases that actually require highly custom UI, but if you’re doing either of those you’ve probably outgrown any kind of cross platform solution anyhow. Realistically I believe this would work well for probably 80-90% of non-game apps and wouldn’t suffer many of the drawbacks that usually come with “silver bullet” style cross-platform setups.
I'm hoping that Swift becomes sufficiently viable on Android that I can reuse library code across iOS and Android sometime in the next few years.
Jetbrains moves pretty fast and the integration works surprisingly well for something this young.
In fact I think the high quality of jetbrains IDEs might actually impede Kotlin tooling development… why bother when first party tools are so good?
Swift doesn’t suffer this issue — it’s been built for multiplatform use from day 1. There are still some discrepancies, but today Swift on Linux is about as usable as Swift on Apple platforms. There’s even several (4+ last I checked) modern web frameworks for Swift and even GTK+ bindings.
On top of this, its Windows port recently reached a useable state and there’s work being done on a Win32 bindings. Once that’s done, it will be possible to write an app with a common core and 3 different UI layers all in Swift which connects to a web API written in Swift. That’s already leagues beyond what was ever achieved with Obj-C and momentum is continuing to build.
You could use Java/OpenJDK or even Kotlin/OpenJDK.
You could use dotnet core.
You could use Node.js with Typescript.
All those are mature and support all major operating systems way better than Swift does.
I'm not sure what Swift's Unique Selling Proposition is. From where I'm looking it seems to be: "it's backed by Apple".
Eh, I wouldn’t say that. I don’t see it significantly ahead of say GNUstep is for Objective-C; Swift on any platform other than macOS is still pretty much a second-class experience.
However since it is still beta, this might eventually change.
And it does require getting licenses for Clion and AppCode, for the full developer experience regarding Kotlin/Native, versus C++ that is already there in XCode and Android Studio.
Oddly enough, this is what we're going with...
Microsoft used the term hamburger development at their CppCon presentations, with the meat being the C++ code and the bread for the native glue and views. :)
Naturally one can use something else other than C or C++ for the library code, but then there is the additionall effort of adding yet another toolchain and debugging layer into the process.