
Why Kotlin is my next programming language (2015) - insulanian
https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3
======
charlieflowers
I am a bit in a hurry, so I acknowledge I only quickly scanned the article.
But it struck me as damning by faint praise.

Like a waiter advising, "Choose the chicken parm. It doesn't have any bones,
all the salmonella has been cooked out, and it doesn't have any bad flavor."

If I'm going to be successfully pitched a programming language, I will need to
see its power of expression or be shown how it solves some problems that other
languages don't address well. Some "special sauce."

No offense intended ... that's just my quick take.

~~~
lmm
I think that might be what's needed for a really good programming language. If
you want a general-purpose language, you probably don't want something unique
and envelope-pushing - you just want a language that avoids all the mistakes
that are so common, that learns from what's gone before. Like buying a table -
you usually don't want a radical table that can do something other tables
can't, you just want a good solid table.

(I don't think Kotlin is such a language - I think Ceylon might be. I work in
Scala at the moment)

~~~
a-saleh
It is interesting that when I considered next language to write a side-project
in, I was choosing between Ceylon and Kotlin.

In the end I did choose Kotlin. My reasons included:

* support in IDEA

* focus on java interoperability

* nice interop with android

but the main thing probably was, that I trust JetBrains that they will support
Kotlin in the long term, while I don't think RedHat has any projects depending
on the language.

So, why would you choose Ceylon?

~~~
lmm
Well in reality I choose Scala, largely because it has a level of maturity and
ecosystem support (both libraries and other tools) that neither Ceylon nor
Kotlin can match. But I'd use Ceylon rather than Kotlin because I think it's a
much better designed actual language (see cousin post for examples). I
personally dislike IDEA (prefer Eclipse), and I don't think Kotlin actually
has any better Java or android interop than Ceylon (or Scala), they just make
more of a fuss about it in their marketing.

~~~
premium-concern
> they just make more of a fuss about it in their marketing

This succinctly describes many aspects of Kotlin.

------
izacus
Wow, so much negativity here O.o

Kotlin is getting rapid adoption in the Android community and is quickly
getting the same status as Swift has in the iOS world.

The main reasons for the rapid adoption are:

\- It's designed to easily integrate into existing Java codebases. This means
that starting to use Kotlin is pretty much a case of adding two Gradle
dependencies and source files into `src/kotlin`. Interop with Java is painless
and doesn't require any special boxing as opposed to some other languages.

\- It's standard library is small (~700KB), which is a stark contrast to Scala
and some other JVM languages, which pretty much demand usage of ProGuard while
developing due to large method count.

\- It's performance characteristics are close to Java and doesn't cause
catastrophic GC collection issues like some Clojure code does.

\- It has pretty much all the features expected from a modern language
(nullability, const values, concise syntax) while still keeping code very
readable for people who already know Java. The adoption in our Java codebase
has thus been rather painless, since code doesn't do any additional magic you
wouldn't expect.

\- It compiles code to Java bytecode which runs on Java 6 JVM, which is
critical for Android.

\- It has first-party support in IntelliJ IDEs, which includes Android Studio
itself. The IDE experience is significantly better than Scala or Clojure one
and almost on par with Java.

So in short, we got a modern language, which is easy to transition to from
Java 6, gives seamless interoperability with existing Java code (you can just
start writing Kotlin classes in your Java code base), doesn't add overhead to
your Android application and doesn't behave strangely performance-wise. There
are still some warts to fix (mostly related to static checkers), but Kotlin
has been a huge win for Android world.

~~~
Razengan
> quickly getting the same status as Swift has in the iOS world.

What's keeping Swift itself from eventually becoming the preferred language
for Android as well?

~~~
kmiroslav
It's a non starter as the main language since it's not JVM based.

As a C/C++ alternative for native development on Android... possibly.

This will be in great part decided by

1) How frustrated native Android developers currently are with C/C++ (I don't
have the feeling they are much) and

2) How much resources Apple will dedicate to make Swift viable on Android
(hard to imagine they would be that interested helping out the #1 player in
that space while their #2 spot is shrinking on a daily basis).

------
Scene_Cast2
I tried Kotlin during the Surprise Language round of Codeforces, a programming
competition.

I found it to be more verbose than a typical modern scripting language. Maybe
it's the result of choosing the least of the evils for what it's trying to
accomplish.

The other drawback: the documentation. Kotlin's reference documentation
(looking up how to properly use a call) does not have any examples. I'm not
even talking about full compilable examples - although that would be nice, it
doesn't even have one-liner examples. FWIW, I was trying to look up how to use
a comparator to sort a MutableArray<Int,Int>.

~~~
rattray
Personally I don't much mind the added verbosity, coming from Ruby/Python/JS,
so long as I don't have to write so many damn tests. Speaking from minimal
experience, Kotlin still _seems_ like a big net win here. Same is true of
other languages with lightweight, static type systems like TypeScript/Flow,
Swift, and Go.

I agree about the documentation – I think it's one of the biggest reasons the
language has seen such little adoption given its benefits.

I couldn't even find how to integrate Kotlin files into a Java project without
using IntelliJ. Kotlin is developed by Jetbrains, so of course they're used to
IDE-driven-development, and have a financial stake in people using their
products for development. But coming from scripting languages, this sort of
documentation gap was a real turn-off for me.

~~~
Bromskloss
What is it that makes you not having to write so many tests?

~~~
iends
Static typing.

~~~
Bromskloss
Is the reasoning that you then don't have to test what happens if you pass a
parameter of the wrong type to a function?

~~~
bbcbasic
The compiler guarantees it won't happen. Such a test would be a test of the
compiler and in my opinion unnecessary. And in Haskell at least... impossible.
You can't write the the test because IT won't compile!

~~~
Bromskloss
I understand that. My question is if that is the kind of tests that people
have in mind when they say that static typing requires fewer tests.

~~~
bbcbasic
I can't speak for anyone else but I believe so yes.

------
vbezhenar
For me Kotlin is almost a perfect replacement for Java. It has very few
drawbacks, but generally it's much better and it's a pleasure to use it. Not
to mention solid IDE support. I've used Kotlin in two small projects. One
project was completed year ago and now I'm improving it. Kotlin is just
awesome when it comes to refactoring or generalising. Much better than Java.

I don't want to compare it to Scala, they target different auditories, IMO. I
tried Scala, it's a lovely language, but it's too complex. I had to spend a
month before I was able to write a quality code using Scala and I still had a
lot of problems reading scala collections source code or even understand
scalaz. On the other side I spent one evening reading about Kotlin (awesome
and very complete, yet small documentation definitely helps) and I knew the
language, could read its standard library and write production-quality code.
For me that's a deal breaker.

~~~
kailuowang
Yes scala is complex, but your scala code doesnt have to be. The reason that
std collection lib and scalaz code is hard to read is their inclination to
push the limit of utilizing the advanced scala features to make their usage
really easy.

That being said scala is not for one who wants to plateau quickly. It takes
years.

------
korm
With the exception of compiling to JVM, _Dart_ is worth looking at if you
liked this. Most of the article applies to it as well:
[https://www.dartlang.org/docs/dart-up-and-
running/ch02.html](https://www.dartlang.org/docs/dart-up-and-
running/ch02.html)

With dart news in the past 4 years, the knee-jerk reaction has been that
Google will abandon it, which unfortunately means that not much discussion
ever went to its merits. Adopting the language has provided a huge
productivity boost for me and many other developers, in or outside Google.

------
thirdreplicator
Features: ========= * compiles to Java and Javascript * null safety
(optionality) * Lean syntax * Exceptions are unchecked. * Extension functions
let you add methods to classes without modifying their source code. * Operator
overloading * No macros * Markdown instead of HTML for your API docs * Better
Java generics. * Delegation (forwarding methods) * String interpolation

Seriously underwhelming....

~~~
jsmith0295
I initially used Kotlin for a project at work, and I would agree that it is
underwhelming. Pivotal had announced official support for Kotlin with Spring
Boot, which is what motivated me to give it a try. However, there was no
support for the @Transactional annotation in Kotlin at the time, so I ended up
writing a decent amount of Java anyways. Then there was a compatibility issue
with one of our internal libraries, and I had to rewrite all of the
controllers in Java. By the time the project was finished, the majority of the
code was in Java, and I hadn't really gotten any benefit out of the Kotlin, so
I decided to just use Lombok and replace all of the Kotlin code with Java. My
builds got about 3 times faster after that because Kotlin seems to have
performance issues with Gradle.

The 1.1 release is promising many features that make me want to revisit it,
though: [https://blog.jetbrains.com/kotlin/2016/04/kotlin-
post-1-0-ro...](https://blog.jetbrains.com/kotlin/2016/04/kotlin-
post-1-0-roadmap/)

~~~
vbezhenar
As of 1.0 Kotlin has solid Java compatibility, @Transactional definitely
shouldn't be an issue. What features are compelling for you in 1.1? They are
nice, but generally just a nice sugar. I don't really miss any of those. I
suggest you to try it now, if you have a chance.

~~~
jsmith0295
The @Transactional problem was fixed, I shouldn't have left that out. I had
first tried to do this pretty much immediately after the 1.0 release.
Async/await is cool, but it's really the idea of adding channels and
coroutines that I'm a fan of. We've also generally stopped using that library
that didn't work with Kotlin controllers for any new projects, so Kotlin is
definitely something I look forward to using again.

------
_Codemonkeyism
I've switched from Scala to Kotlin after 8y of Scala. There are some things I
miss (e.g. Options and Futures) but Kotlin feels much more focused on real
world problems.

And Gradle is so much easier than the monster that is SBT.

~~~
vorg
Gradle 3.0, due out soon, will provide Kotlin as an alternative language for
writing build scripts, so you'll be able to use a single language for
development, as you did when you used Scala with SBT.

------
PascalW
When I tried Kotlin some time ago on a side project I wasn't very impressed.
To me the problems Kotlin is addressing are not that huge. It feels like
having to switch to another language (albeit very similar to Java) just to fix
some annoyances is just not worth it.

Maybe prior to Java 8 this would've been more interesting. I also wonder how
much time it will take Kotlin to start benefiting from Java 9 features when
that gets released.

~~~
jmfayard
Keep in mind that "Prior to java 8" is a time that belongs to the distant
future for the android world

------
ld00d
I really liked Scala when I played around with it (bare with me here), but
when deciding on what to use on a project I'm starting, targeting the JVM is a
downside. Can I depend on the JVM being on the target machine? If not, I'll
have to deal with the dependency. However, if I choose a compiled language
like Rust, I don't have to worry about that.

~~~
eropple
Under what circumstances are you writing software for deployment in places you
don't have administration access on (i.e., your servers, which should be
deployed with CM as-is and make adding dependencies trivial) where you cannot
package OpenJDK (this is trivial on Windows, OS X, and Linux), cannot expect a
system administrator to install the JVM, _and_ can expect Rust to run?

There is a slice of the universe where this exists, but it's not really
Kotlin's target in the first place (and I think that's basically self-evident
from everything around it) so I'm not sure why you'd try to jam that square
peg in the round hole to begin with.

~~~
ld00d
I'm thinking of client machines. People balk at installing Java these days. Is
there a way to get the JVM without Java?

Is Kotlin not capable of being a client application?

~~~
tormeh
You just package the JVM with the application itself. Create a
.bat/.exe/.sh/binary file that calls the JVM with your program as the
argument. It's simple, but it will increase the download size of your program
significantly (unless your program is huge - then it doesn't matter)

~~~
maxxxxx
No installer needed? Just copy the files somewehre? That would be nice.

~~~
eropple
Sure. Plenty of Java-based games do this.

~~~
freekh
This may come off a bit snarky but is there really plenty of Java games out
there? If so, anything anybody might have heard off?

~~~
Nullabillity
Minecraft was somewhat popular a few years ago. :P

Runescape also used to be a pretty big one, even if it's been shrinking lately
AFAIK.

------
eggy
I know they don't have the 'production-ready' stamp, but if I were to jump
back into the JVM world it would be Frege at this point. It is basically a
Haskell on the JVM. It compiles to Java source code, so you can work it in
slowly to your real project [1]. You can call Java from Frege, or Frege
functions from Java.

ABCL - Armed Bear Common Lisp is another, but Lisp on the JVM instead of
Haskell. It's been around for a while, and has become fast for a Lisp on the
JVM, though it's not SBCL in speed. It does however support full 32 bit
integers on 32 bits sytems compared with SBCL's 29 bits on 32 bit systems due
to boxing. Again, not used much in production, although, there are some great
testimonials of some cool implementations [2]. I particularly like the Keck
telescope code written in Lisp in 1994, ported to ABCL and using Java for some
image work and display.

[1] [https://github.com/frege/frege](https://github.com/frege/frege)

[2] [https://common-
lisp.net/project/armedbear/testimonials.shtml](https://common-
lisp.net/project/armedbear/testimonials.shtml)

------
ScottBurson
Hmm, this does seem like a pretty tasteful design in many ways.

The declaration-site variance for generics is a pretty good idea, but is still
inadequate to deal with _functional_ collections. (I use the term "functional"
as opposed to simply "immutable": an immutable collection has no update
operations at all, while a functional collection has functional update
operations: for example, given a set S and an element X, to compute a new set
whose elements are those of S together with X (S ∪ {X}). This usage is
certainly not universal, but the distinction needs to be drawn somehow.)

Anyway, the point is this. Kotlin has in its collections API

    
    
      interface Set<out E> ...
    

where the use of 'out' says that given types A and B where B is a subtype of
A, 'Set<B>' is a subtype of 'Set<A>'. But then if you wanted to add a 'with'
operation as described above:

    
    
      interface FunctionalSet<out E> : Set<E> {
        fun with(E elt)
      }
    

you can't do it, because type parameters marked with 'out' can't be used for
method parameters.

~~~
lmm
The correct signature for that method is something like (don't know whether
this is the syntax)

    
    
        fun with<F super E>(F elt)

~~~
ScottBurson
I guess you mean (note the return type)

    
    
      fun with<F super E>(elt: F): FunctionalSet<F>
    

That's an interesting suggestion, but I don't see any indication that Kotlin
provides for type _lower_ bounds in generic function constraints. (It does
have type upper bounds; see the bottom of this page:
[http://kotlinlang.org/docs/reference/generics.html](http://kotlinlang.org/docs/reference/generics.html)).

------
hiyou102
I see the biggest market for Kotlin being Android. It manages to provide
features that Java will likely never have while still having a fairly small
impact on run time, deploy, and APK size. The conversion tool is really great
too. It makes it much easier to migrate a project to kotlin, especially when
trying to figure out more complex stuff like annotations. I see Kotlin being
Android's Swift in the future.

~~~
on_and_off
I would love to see that happen (or something similar, like Swift).

I fear that it will be hard to move in that direction as long as Google does
not push in that direction though.

The official word is that we don't need their support in order to write
Android apps in Kotlin, which is true and that the gap between objC and Swift
was large enough to justify the change but that Java is not that old, which is
debatable.

In all cases, it is hard to argument the move to a new language in an existing
codebase when there is no official push in that direction.

If I have to create a new app in the near future, I will strongly consider
Kotlin, but for the 8 eight old codebase I have to deal with + the 15
engineers working on it, my hands are tied.

~~~
izacus
> In all cases, it is hard to argument the move to a new language in an
> existing codebase when there is no official push in that direction.

I don't understand the logic behind this sentence? Why do you need Google to
push you somewhere instead of you youself choosing a more productive option?

Kotlin is designed to be easy to integrate into existing Java codebase and our
introduction to a largeish Android codebase has been a great success.

~~~
on_and_off
For a personal project or for creating a new app from scratch where I am lead
engineer, sure Kotlin would be an easy choice.

However, right now I am a senior engineer working on a 8 years old android app
alongside 15 other Android devs.

The switch to another language is not even something that the current lead or
the CTO are willing to consider.

In their defense, we would have to train the whole team, this would be a major
task and build times are already a big issue so anything degrading them is
hard to push for.

A push from Google would help a lot, it would remove a lot of objections like
"this is hipster shit" or "I am not going to learn the language of the month"
(coming from people who have not learned any language in years) and force them
to take it seriously.

Even the iOS team barely use Swift though, so I don't see it in a near future.
I guess I just have to search for another company.

> our introduction to a largeish Android codebase has been a great success. Do
> you mind sharing some details ?

------
kmiroslav
Should probably be renamed "Why Kotlin is my current programming language".

------
Buttons840
Are there any decent languages that compile to readable Java? I think such a
language would have a place in conservative Java shops, where management
insists "we only use plain old Java around here". You could program in a
"cleaner Java" translate it to vanilla Java, then commit, and nobody would
know the difference.

~~~
tigershark
If you ever tried to push some Java-generated code in the repository I will
never _ever_ approve your pull request. It's simply one of the most wrong
thing that you can do on so many levels that I really don't know from where to
start. You will need to keep track separately of the kotlin code and Java code
and keep them in synch. You cannot use the repository because, per your
admission, you are doing this in secret, so if your machine dies then you lose
all the original kotlin code. Even if you didn't lose the original kotlin
source future iterations of the language may change the generated code, so
even if you simply remove a comment your pull request will have changes in
pretty much all the generated files. A simple refactoring can have similar
effects. Generated Java code in my experience can be spotted immediately given
that usually is _very_ verbose. I simply can't imagine what huge amount of
code that thing will generate for a simple one liner using streams, given that
it's targeting Java 6. Probably there are many more other reasons that I
cannot think of early in the morning. Last but not least, I'd rather never
work with someone that tries to deceive all his colleagues and pushes in the
repository awful code. If you don't want to use Java then find another job,
nobody is forcing you to work there.

~~~
Buttons840
Have I ever committed auto generated Java?

Yes. At one job my predecessor had done significant work in Java and somehow
the only the compiled files were left behind. We reverse compiled them and
that was my starting point for the project. As you can imaging the generated
code was perfectly formated, with a very consistent style, and generic
variable names. It wasn't terrible to work with.

The language I'm proposing probably couldn't be too different than Java. But
one trivial example would be to make all variables final by default unless
they were marked "notfinal". This would be different than Java, and thus would
be a new language. And it would be trivial to translate back and forth between
this language and Java. Nobody could ever tell the difference. Granted all you
would really be changing is syntax, which may or may not be worth while.

------
Waterluvian
How important is a name for uptake? I think this one might actually have an
impact. Not sure why. It just looks and sounds weird.

I would love to learn more about languages and marketing. Off to Google!

------
voddan
A few people mentioned problems with Kotlin documentation (presumably with a
connection to the Surprise Language round of Codeforces).

Could you describe in detail the problems you had? What was unclear or
misleading? Were those problems with the JVM setup or Kotlin itself?

------
ternaryoperator
>Kotlin costs nothing to adopt! It’s open source, but that’s not what I mean
here. What I mean is there’s a high quality, one-click Java to Kotlin
converter tool, and a strong focus on Java binary compatibility.

The costs of adopting a new language are greatly more significant than implied
here. The time it takes to learn it. The time it turns to learn the tools that
are specific to it. And if you put it into production, the technical debt
you've created by adding another language to the codebase, etc.

If the OP had said that you don't have to start a green-field project to use
it, that would be more accurate.

~~~
mike_hearn
My experience has been that the learning curve for Kotlin is extremely shallow
if you're an experienced Java developer. This is not just my experience but
also the experience of building a team that's working with Kotlin all day.

One reason the cost is low, is that there aren't really many tools specific to
Kotlin (or any, really). You can use the same IDEs, the same build toolchains,
the same libraries, even the same standard library as regular Java.

~~~
eropple
Upvoted you, but adding on: a competent Java developer can pick up Kotlin in,
literally, three hours. The mappings to Java concepts are trivial, but the
language's niceties quickly bear themselves out as you go.

------
hnxx
Kotlin reminds me of coffescript to JavaScript.

~~~
highwind
As far as I know, all CoffeeScript did was add bunch of syntactic sugar on top
of JavaScript.

I believe Kotlin actually adds programming paradigm that's not in Java on top
of terse syntax, i.e. real closure, operator overloading, pure object
orientation, and more.

~~~
lmm
Java already has real closures and pure object orientation. Operator
overloading is just sugar.

------
bbcbasic
It's the least sexy name for a programming language this century

~~~
scrame
Groovy won that 10 years ago.

~~~
vorg
Groovy was named by its creator, James Strachan, in 2003. By 2006 (i.e. 10
years ago), he had been managed out and a business sort without technical
knowledge had taken over. He's since slowly wrecked Groovy's sexy brand and
placed it firmly in the Java camp. I tried reversing the trend with stuff like
"grOOvy", and the Groovy grrrrrrowl, Ooooooooo, and Vy (for "victory") but
that business person running Groovy skuttled the effort, appearing far more
interested in retaining his centralized control over Groovy branding. Groovy's
since been handed over to Apache, being run by a 10-member "Project Management
Committee", only 4 of which actually do any technical work on Groovy's code
base. The other 6, including the "PMC Chair", just do administrative fuss.

------
amaks
What happened to Scala? Wasn't that the #1 language for JVM?

~~~
lmm
Scala is still there, still growing, and a much better language. Kotlin is
founded on this anti-intellectual rejection of Scala's advanced features...
only to then add them back in piecemeal. So rather than a single powerful
general feature like implicits or higher-kinded types you have language-level
special cases like extension methods and specific nullness operators.

(Don't get me wrong, there are plenty of things Scala would do differently if
it were made today - there's space for a language like Ceylon that makes a
genuine effort to simplify on what's in Scala)

~~~
sgift
> Scala is still there, still growing, and a much better language. Kotlin is
> founded on this anti-intellectual rejection of Scala's advanced features...

Each time someone brings up Scala there comes this weird "people who don't
like it are anti-intellectual" \- well no, people don't like it because it
looks weird, had for the longest time abyssimal IDE support, tries to do
things which have been solved in production by itself (see SBT vs Maven) and
is a mishmash of more or less every idea that was floating around mixed into
one language.

Kotlin has a very specific focus: Being usable for a working Java programmer,
who doesn't have three years to learn every weird idea Scala tries to shove
down your throat. It uses existing tools, existing Java collections and
enhances them instead of saying "well, we do everything new, because we know
how to do it 'better' and we don't care for your existing code."

~~~
Nullabillity
Ultimately, you don't need to learn every single Scala feature to get started
using it. As a Java developer you only need to learn a few differences before
you can start using it as a "Java with better syntax" (var/val/def,
static/object, Object/AnyRef, void/Unit, interface/trait, <>/[], []/()),
learning the Scalaisms later on as you go.

You don't need Scalaz to write Scala code. You can even ignore most of the
standard library while you're starting out, and use the Java equivalents.

SBT might seem pointless at first, but the same thing applies there. You don't
need to use it, plugins for Maven and Gradle are available. But once you do
switch, you'll see how much nicer it is.

------
sgarman
The author talks a bit about how he ended up back in JVM world when they
started on Android dev. I just want to note that Android does not use the JVM
but Dalvik (I think it's actually called ART now). Maybe they just meant
Android put them back in the world of Java.

------
on_and_off
Kotlin is unquestionably a very large improvement over plain old Java.

I fear it might be very hard to make the Android community adopt it massively
though, unless Google pitches in and supports it officially.

~~~
kmiroslav
The Android community has already adopted it pretty significantly (join the
#android Kotlin slack and see for yourself).

And this was done without any official support for Google because... it's not
necessary: Kotlin works out of the box. Which is one of Kotlin's strengths.

~~~
on_and_off
I am in that slack channel.

Do you have any adoption numbers though ? From what I see in the local
companies, kotlin is still very rare, except for a couple of startups (which
makes them very attractive tbh). That anecdotal evidence of course and I would
love to see a tide change but hard numbers would be an huge help.

------
Ericson2314
> Kotlin comes from industry, not academia. It solves problems faced by
> working programmers today. As an example, the type system helps you avoid
> null pointer exceptions.

I'm sorry but you just undercut your own anti-intellectualism better than I
could right there.

(There exist languages which have guarded against this without loss of
expressive power since _before Java_ and, oh, are from academia.)

~~~
ansgri
A better example of 'engineering not academy' would be explicit vectorization,
memory layout support and a good FFI. (all the stuff that in theory is better
managed by compilers, in practice it either doesn't matter at all or else
should be left to humans).

Please correct me if I'm wrong, but Kotlin doesn't improve on Java in these
areas.

~~~
premium-concern
Have a look at Scala Native.

Despite its young age it creates really fast, tight code (they have issues
benchmarking things because Dotty Linker + LLVM gets rid of too much stuff).

~~~
ansgri
Thanks. It is too early to say if it would be of any use, however, since they
don't talk about freeing these native data structures.

~~~
premium-concern
You can have both managed (T) and unmanaged pointers (Ptr[T]).

------
marvel_boy
We're in 2016 and Swift is the new rage. In no time it will be the new
multiplatform mobile default option.

~~~
yomism
Android I don't think so... There are tons of Java code in the Android
ecosystem and their developers hate anything that comes from Apple.

So it will end as iOS only.

