[nawtacawp]

Perhaps this is the start of moving Android Apps to Swift.

Which, per rumor was considered last year:

"About the time Swift was going open source, representatives for three major brands — Google, Facebook and Uber — were at a meeting in London discussing the new language. Sources tell The Next Web that Google is considering making Swift a “first class” language for Android"

https://thenextweb.com/dd/2016/04/07/google-facebook-uber-sw...

[adamnemecek]

If I were Google I would just invest into the native, LLVM-backed Kotlin thing. I guess the advantage of Swift would be using 1 lang for 2 platforms but at the end of the day the APIs are different enough that idk if it would matter.

[DannyBee]

As mentioned above, this fork is for staging patches written by some folks that are part of an internal-facing IOS tooling team.

Nothing more. They aren't related to or even located organizationally anywhere near Android.

[rainboiboi]

That would be great news. Unification of mobile programming language.

[rectang]

That would be great for developers like you and me -- after all, our skills are most valuable when they are portable. How much more can we get done if we don't have to support multiple platforms?

However, the interests of vendors are diametrically opposed to our interests as developers -- it is all about vendor lockin, and making it as hard as possible for us to support competing platforms.

[rtpg]

I understand the theory, but in practice this means if you want to implement a competing platform... you just need to write a Swift target!

Much easier for developers to go check out your platform.

More unification would likely also mean better abstraction layers across platforms, meaning that competing platforms could rely on those abstraction layers.

Think about how nice it is that most devices out there are running at least a flavor of Unix. You have a base-level expectation of how things can be integrated. There are of course differences, but generally if you write your stuff in a certain way you can use it almost everywhere!

And for those who don't want to work on Unix, all you need is a compatability layer to bring over some useful tools. Just get that C compiler up and running and you get a lot of stuff too!

The reason this is different from other forms of platform lock-in is that ultimately things like programming languages don't cover the full stack, so there are "obvious" places where you can swap either your language, the stuff underneath, or the stuff above it.

[ringaroundthetx]

React is good enough for most of the mobile projects out there.

Hint: its none of the ones you use.

[reustle]

React Native hasn't lost its PATENTS file yet, so no other large company would bank heavily on it.

[ringaroundthetx]

yeah but we're not talking large companies

[devdoomari]

maybe 'was'? kotlin is the official google's recommendation for android now... (and kotlin can have multiple 'backends' -- e.g. build-to-java / native / web / etc)

[philwelch]

Kotlin could just be a stopgap, though. It’s still a JVM language so it’s an easier migration, and from what little I’ve seen it doesn’t add very much other than syntactic sugar for null checks.

[mdkMM]

I doubt Kotlin is a stop-gap measure, and it does a lot more than just give syntactic sugar for null checks. As the comment above you mentioned it's not only JVM, it has a JS backend and a fully native one which is developing very rapidly. Kotlin and Swift have a very significant overlap in language features, and with how strong the Kotlin community is, I don't see it going anywhere anytime soon. In fact, I would sooner see multiplatform development embracing Kotlin over Swift, given how well it's progressing. Kotlin native hasn't even reached 1.0 yet, and they already made a very convincing showcase of how it can be used to develop server backend + frontend + android + iOS with significant code reuse, and not having to constantly switch language contexts: https://github.com/JetBrains/kotlinconf-app