Swift Ported to Android (opens in new tab)

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

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

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.

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/

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++.

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

Just because they are accessible, doesn't mean using them is seamless. For example all of Objective-C's runtime and classes are available to Swift but there is some friction e.g. methods that emit untyped NSArrays rather than typesafe swift arrays, or cases where you have to avoid using Swift structs because they can't be passed into the Objective-C runtime. Apple's done a lot of hard work, and each release of Swift has made this better, but it's still not entirely without hiccups... without having used Kotlin, I can't say for sure, but I would guess there are some analogous issues.

I haven't ever wrote an Android app (just toyed around and patched a few projects, but never had an idea and a necessity to do a full one from scratch), but what's the limitation here?

Can't a native library call just anything from the Android/Java world?

I mean, NDK library has JNIEnv* pointer and it can call FindClass/GetMethodID/Call*Method. And it can create objects/functions if it needs to be called back. Of course this isn't fun in the raw form, but don't see any reason it can't be well sugared.

The point is lot of application logic can be written in Go and Swift hopefully soon. That code can be shared across iOS / android app. It is still net win for people who do not like Java/JVM.

If all you're doing is Android programming Kotlin is probably a better choice at this time. If you're a Java programmer, Kotlin is probably a better choice. If you're already a Swift programmer...

Also, let's see how both languages gain traction in the next 3-5 years.

Aren't these "performance gains" a wash due to the overhead of ARC?

Don't you still have GC issues for heap allocation/destruction? Swift uses the ARC pattern so no GC lockups or performance issues.

[1] https://developer.apple.com/library/ios/documentation/Swift/...

True, but Microsoft is such an enterprise company that it fits their customer base really well (e.g. "I don't care if it's pretty, I just need an inexpensive-to-build app for my 3,000 workers that runs on either platform").

I think most people don't understand Xamarin. Up until pretty recently Xamarin had no cross platform UI components. That is although all logic was shared, views had to be written separately for the different platforms - just like React Native.

With Xamarin Forms this has changed - you can add a Xamarin Form component and this will work adapt itself across the different platforms. The key word there is adapt - it is not like an HTML page, a Xamarin form input will look different on Android and iOS by default.

So I think your point, while valid, does not apply in any way to Xamarin!

but i would say for writing business apps, this isnt really an issue

most business users would accept that their apps, look slighly ... unlike common apps on the platform

Do you have anything to back that up?

C# has always had support to AOT to native code since the early days via ngen. The only issue was that more effort was spent in the JIT compiler and ngen requires dynamic linking.

C# is compiled to native code on Windows Phone since version 8.

The C# extensions for Singularity (Sing#) and Midori (System C#) generate static binaries. Work which served as starting point to MDIL on WP 8.x and .NET Native.

The new .NET Native compiler even exposes SIMD.

Mono also supports AOT compilation since a long time.

As always language != implementation.

You are correct but part of the work being done to get .NET native working is the aot compilation. https://blog.rendle.io/what-ive-learned-about-dotnet-native/

.Net Core can compile AOT as well, and Xamarin already does that on iOS with its Mono runtime too.

ART also compiles down to native code. As for performance comparisons - last time I checked the benchmarks for Java were still faster than Swift.

Well, Visual Studio Code[1] is, so it may be coming in the future.

1: https://www.visualstudio.com/en-us/products/code-vs.aspx

> How much does it cost a license for Visual Studio?

Free if your revenue is under $1m, then $40/month including CI, source hosting and issue tracker.

it's worth also asking:

How much does licensing a set of Windows keys run?

How does the .NET GC impact me versus Swift's ARC?

How much RAM does Visual Studio eat up after you've been coding for a while?

How slow, unresponsive or buggy is it these days?

of course there's "ecosystem creep"... If I'm going C# on mobile, I'll naturally be influenced to consider C# on the server... how much do Windows servers cost? and since they're a "first class citizen" on windows, what about SQL Server?

This was my thought. What is Microsoft's answer to Swift?

What do you mean?

That's correct-- Swift's native String/Array/etc. are part of Swift's native stdlib.

NSString/NSArray and friends (along with the bridging code to go between them and the Swift stdlib types) are part of the open-source Foundation, though. Eventually, that should be present in any reasonably complete Swift runtime environment-- it includes APIs, like networking and date/time handling, that would typically be considered essential but aren't part of Swift's stdlib.

If you think of C and C++ point of view, yes.

On the other hand the Frameworks are quite expressive for applications, but one needs to use Java 6.5 or resort to third party solutions like retrolambda and Kotlin.

Don't expect to write entires Android apps in Swift. The best thing we can hope for is sharing crossplatform code among iOS, Android etc. And with Foundation ported this is fair amount of code.

There is a difference between "starting a brand new app on Swift" and "porting a long-existing Apple app to Swift". How many new apps Apple had started after Swift announcement?

Swift 3 is expected later this year with a fixed ABI. Once that happens we will start to see Swift-only APIs being made available for iOS frameworks.

Most of the existing apps aren't written in Swift because they predate Swift's creation. The balance will change over time.

Parts of OS X El Capatian are written in Swift . Source :

http://daringfireball.net/thetalkshow/139/federighi-gruber-t...

"FEDERIGHI: We have all types here within Apple. They start out with the “I love Objective-C. I don’t want to change” to “OK, maybe there’s something to this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through all the phases internally. You know, we’ve had some really great adoption by teams like … the team that does the Dock and the window management on OS X, implemented all their new features for El Capitan in Swift and started mass-converting all of their code, and say that they couldn’t imagine going back and that they’re more productive with it. Part of what our internal teams need to deal with, though, is that they’re working on, let’s say, the current version of Swift 2.0 while it’s not done yet. I mean, while it’s not even WWDC-level done yet, right? And they’re working on the interfaces in terms of our internal frameworks that haven’t been modernized for Swift. And so, they’ve got it rough. They’ve got to really love it to make that leap because they’re working on a very, very bleeding-edge environment when we use it internally. Thankfully, with Swift 2.0 now well out the door, that’s stabilized things a good bit and they’re really open to it.

But there’s been just lot of feedback. And a lot of it has helped with the impedance, making sure the impedance between Objective-C and Swift is absolutely minimized because of course we have and will continue to have and continue to write more Objective-C code, and so the ability of Swift and Objective-C code to work together completely naturally is a huge focus. A bunch of things like generic collection, support for lightweight generics in Objective-C, were big pain points internally and something we fixed in the language, and is now great for all of our app developers externally. So, it’s been a not dissimilar road for us internally to what you see outside. But in terms of Swift and writing big apps, it’s certainly the case that when Swift 1.0 came out — heck, we didn’t support incremental compilation in the very first update. And so that was going to be a limiting factor for productivity for people who had big apps. A lot of that stuff has changed. And then in 2.0 having a good error-handling model, having the availability check so you could span API versions — these sorts of things. I think it really addressed the vast majority of pain points that we were experiencing, that I think the community was experiencing about writing larger apps. And so much about Swift is actually inherently better for building big apps because it handles modules and namespaces in a way more naturally than in Objective-C. It makes the API contracts a little more clear, the code more obtainable. So, we’re very comfortable."

WWDC app was done in Swift, IIRC. Not the core app by any means, but still.