
Who will steal Android from Google? - aberoham
https://medium.com/@steve.yegge/who-will-steal-android-from-google-af3622b6252e
======
ocdtrekkie
I think Steve's underestimating the power of Google's control over OEMs here.
Every OEM wants to get rid of Google's hold over them, but how do they do it
without putting their entire corporation at risk? Google has already shown
they'll ban your entire company from Google Apps access if you try to produce
a single Android device without Google Apps.

So any company who wants to exclude Google puts their entire mobile product
line at risk on this play. It'd be hard to see anything coming of this unless
multiple manufacturers can agree to make the jump together, creating a
platform large enough that even Google has to support it for their own market
share needs (which means, this group must include Samsung, who's hedged their
bets on this sort of thing but seems too scared to make the jump). And even
then, this only remains an option as long as the Pixel remains niche. If the
Pixel gains an iPhone-like market share amongst the broader range of Android
devices, Google can mostly tell other manufacturers to screw off.

His notions on cross-platform frameworks making a non-Android platform viable
are spot on though. Not only through things like React Native, but PWAs, which
Google is pretty bullish on itself, despite the fact that it may make Windows
Mobile a viable idea again.

~~~
jbob2000
To your point - software is king. Any two-bit electronics company can ship a
phone, but it's a useless paper weight if it doesn't run the right software.

iPhone is generally behind the curve when it comes to hardware specs, but
nobody cares about that because iOS is such a strong platform.

~~~
ocdtrekkie
And the "right" software is often controlled by one company. If you read a lot
of reviews of Windows Phones, most reviewers seemed to more or less come to
the same conclusion: That Windows was a faster, smoother OS, but that they had
trouble going about their daily lives with it because it didn't have Gmail and
the other five or six Google Apps they relied on.

As long as the market share of any newcomer is low enough, Google can leave
them out in the cold for app support (or intentionally interfere by blocking
YouTube access, similar to what they did with Windows Mobile, and now Amazon's
Echo and Fire platforms), and they'll die off for that reason alone.

Whether it's an Android fork or a new OS like Tizen or some new Windows
flavor, it won't beat Google unless it has the market share to force Google to
support it with apps. And it's hard to get that market share without Google's
support.

~~~
culot
Windows Mobile/Phone actually was less capable than Android on similar
hardware. That Windows Phone had superior resource management was a myth. Even
on high-end hardware Windows Phone struggles to handle things that even a
lower-end Android device can handle.

I don't know if Windows Mobile was ever faster or smoother, but for certain it
was not in the last few years.

~~~
ocdtrekkie
As someone who's spent years using both, I can definitely disagree. Even a
budget Windows Mobile was far less sluggish than my high end Motorola flagship
phones.

In fact, I had a phone with Microsoft's Android Bridge beta, and while people
were complaining how slow the Android apps were on it... I realized that it
was more or less just the normal performance Android apps ran at.

~~~
panopticon
> I had a phone with Microsoft's Android Bridge beta, and while people were
> complaining how slow the Android apps were on it... I realized that it was
> more or less just the normal performance Android apps ran at.

Seems a _little_ disingenuous to pin performance against a half-implemented
ASOP API running on an environment without all of the JVM bytecode tuning
Google has put into ART/Dalvik.

~~~
ocdtrekkie
I wasn't. I carried Android phones as my primary devices for over six years. I
was comparing _that_ experience, to my experiences with the Android Bridge.

------
roel_v
Isn't the complaint about Android as a dev platform related to the frequent vs
infrequent developer article that's now also on the first page? Sure
programming Android is yucky (I struggled with the flavor/build/whatever
hierarchy he mentions just this morning, and it's a mess, and even the
examples in the official docs are incomprehensible), but so is programming on
every mature platform. I write MFC code pretty much every day, and I dig down
into win32 at least weekly. Ya it ain't pretty, but I paid the learning price
15 years ago, and now I know every nook and cranny and I can just get things
done without googling every little thing, and chasing down if that answer on a
forum from 2013 still applies (or is no longer a 'best practice' o how I
loathe that term, but I digress...)

And sure, the 'getting started' examples of every new framework or platform
that promises to fix the warts of the previous one look compelling - but then
you start building actual applications, and people find out they need to add
this and that and by the time it matures we're 5 years on; and it has
accumulated just as much (different, but just as much) cruft as the ones
before it.

~~~
pjmlp
I lost track with MFC during the early 2000, but from the documentation, it
hasn't been rebooted half as much as Android has.

And if the Java layer is already a mess, with the documentation scattered all
over the web instead of Android docs, those of us that adventure in NDK could
use a quote from Dante.

------
lev99
Microsoft invests heavily in Xamarin, but I haven't seen an amazing cross
platform app written in it yet, even though it's four years older than React
Native.

React Native is really good, but I wounder how many developers will be able to
move from OOP or Web development to Declarative Programming.

I think we'll continue to see a lot of Kotlin and Swift developers for the
next decade, as both languages are still attracting many new developers.
Android and iOS have been playing nicely with the compatibility layer, but
could potential break it if they begin to lose control of the market place.
Developing in React Native, while having lower costs, is still more risky than
having two native development teams.

~~~
ocdtrekkie
Microsoft feels like it always is moving towards a grand unifying vision, but
it is always taking longer than you'd expect. Xamarin is still one of many
heads of the great .NET hydra. Microsoft's been making big strides to tame
them all under .NET Standard, but there's still plenty of work to go.

~~~
lev99
imo Microsoft has a problem of trying to force technology when it just isn't
elegant engineering. Unifying .NET is both an engineer's fool's errand and one
of the most obvious things things they can do to improve their business.

I was writing some dotnet core 2.0 code the other day and was shocked to find
it was missing an officially supported odbc as well as many of the System.Data
classes that use to be a big workhorse for developers. .NET has serious
problems.

Microsoft invested in other technologies that were obviously doomed from an
outsider's perspective for far longer than they should. Windows phone and Bing
being the two biggest and most obvious stubborn failures.

~~~
ocdtrekkie
Bing is hardly a failure, nearly every search engine that isn't Google has
switched to it as a data source, and it's market share is growing. Bing's at a
third of US search (according to Microsoft, at least):
[https://arstechnica.com/gadgets/2017/08/bing-is-bigger-
than-...](https://arstechnica.com/gadgets/2017/08/bing-is-bigger-than-you-
think-microsoft-boasts-at-33-of-us-searches/)

A lot of companies now compete with Google in one or several markets, and
being forced to include Google Search would be fairly painful for a lot of
them, so Bing tends to be an immediate contender for anyone who isn't Google
trying to integrate search capabilities. Obviously, a fair segment of their
market share is just "Bing is default on Edge/IE, and Edge/IE is default on
Windows" as well.

~~~
lev99
8.06% of market share isn't exactly a failure, but I suspect it loses money.

[https://en.wikipedia.org/wiki/Web_search_engine#Market_share](https://en.wikipedia.org/wiki/Web_search_engine#Market_share)

~~~
ocdtrekkie
Baidu is pretty much limited to a single country, mind you. And Yahoo uses
Bing data, and almost certainly pays Microsoft for it.

Microsoft almost certainly spends a lot less money on Bing than Google spends
on Google Search, there's a good chance that Microsoft's spending per search
query is lower than Google's. Bear in mind, being "good enough" costs
significantly less than being "the best".

Also, Microsoft announced that Bing started being profitable in 2015, and
they've grown since: [http://www.zdnet.com/article/microsofts-bing-search-
business...](http://www.zdnet.com/article/microsofts-bing-search-business-
finally-is-profitable/)

~~~
lev99
Consider my view on bing changed.

------
tootie
I think a lot of this is objectively wrong. Any of the Cordova-based platforms
(including Ionic, Framework 7 and some others) were built to support every
platform including niche players and it still never got much attention from
developers. Xamarin as well was able to target Windows Phone and it didn't
help. There are already big investments from Android competitors like Samsung
in their mobile platforms and they absolutely suck.

Even then, a solid cross-platform dev platform like React Native is actually a
boon for Android which is second fiddle to Apple when it comes to premium
apps. Right now, anyone looking to reach profitability will go iOS first, then
web, then Android. Making the cost of bridging the gap to Android smaller will
only increase adoption.

~~~
pjmlp
They are pretty big in enterprise apps, usually targeted to employees.

Despite my opinions regarding native UIs, the fact is that we are yet to get
pure native apps contracts, they are either Cordova/Xamarin/Qt or plain web
based.

The majority of enterprise shops do not care about native UI/UX.

~~~
tootie
I'm working on an enterprise app for Android using Xamarin and we are taking
the UX semi-seriously. App looks and performs fine.

I find the concept of "native look and feel" to be extremely nebulous and not
particularly valuable. Apps should look good and be responsive and I don't
notice or care when they look native.

~~~
pjmlp
I find the "native look and feel" concept quite valuable, but my experience in
enterprise, it that most departments either want a "department/corporate look
and feel" or "whatever works look and feel".

Thanks for your Xamarin feedback.

------
RestlessMind
I keep reading about Fuchsia. Maybe, that is Google's answer to the messy
Android stack? I mean, why invest in cleaning up your stack or having a better
cross-platform dev environment, when you can just have a clean new OS?

~~~
oflannabhra
I tried to predict how Fuchsia + Flutter play into Google's overarching
strategic vision in another comment here on HN, and got voted down into
oblivion. My best guess is:

1) Pixels move to Fuchsia, native apps are in Dart/Flutter, compatibility
layer for Android. Fuchsia becomes a distinguishing feature of Googles
hardware, and allows Google to differentiate vs Android competitors.

2) Google continues to support Android, but only as it affects their business
interests (as a funnel for search).

3) Google migrates some service level functionality away from Android and
Pixels become a first-class citizen in Google's ecosystem.

In my mind, Fuchsia is a direct result of Google's newfound interest in
hardware (as a business). I imagine the following:

\- Google sees voice (and maybe AR) as the next frontier, which is actually an
existential threat for them--they are harder to monetize via ads.

\- Google decides to start making hardware (for profit), to monetize their
services (a la Apple). That is, their Voice Assistant is now differentiated
from Android, and to use that service, you have to buy their hardware. Now,
they don't need to make money on ads for voice searches.

\- Google will continue to roll out more ML-driven services that are exclusive
to their hardware, and eventually, exclusive to Fuchsia. This will allow them
to both a) further differentiate their hardware from other Android
manufacturers, b) better monetize their services (effectively through HW
purchases), and c) steal market share of the most valuable customers from
Apple.

~~~
Jasper_
Your problem is thinking they have a cohesive roadmap for Fuschia. Google has
shown time and time again they can't seem to make two teams talk to each other
or think about integrating things at all, and they have no high-level long-
term vision or product strategy.

Fuschia won't replace Android or Chrome OS. It will just be the third OS
product they make.

~~~
oflannabhra
That's fair, I might just be grasping at straws. I for sure don't have the
contacts or insight that Yegge has.

I agree with your point that Google's history has been to take a multifurcated
(and sometimes conflicted) approach.

------
loxs
Off-topic: can someone explain what is it that is so great about Medium, so
that Steve finds it necessary to praise them? To me (as a reader) it's just a
blog engine with horrible user experience. Of course, with time I have come to
accept it as it is, so I don't get angry every time, but I still find it
horrible.

~~~
x0x0
Publishing to the internet, particularly nicely formatted and with a nice
editor, is still a pita. A big pita. Worse if you're Steve Yegge and anything
you write can get a hundred thousand visitors.

I ran a wordpress blog for a while. What a godawful piece of shit that is.
Security critical updates all the time, and HAHAHAHA, they regularly break
themes. I have no idea why, but probably because wordpress refuses to create a
nice them api so they can try and gpl every theme. Plus it's slow. Plus it's
difficult to secure. I had originally used a hosted wp instance until that got
repeatedly hacked. Then I ran it myself. Yuck.

Then I used octopress for a while. I had to configure nginx and ssl and then
deal with things like figuring out why pygments broke. Something went wrong
with python which _obviously_ I'm using inside by ruby blog engine. Mathjax
deprecated their cdn and I'm still too lazy to go fix it.

Medium, imo, creates a nice solution where (1) writing is pleasant, (2)
publishing is easy and comes out nicely formatted, and (3) when you're busy,
you spend the majority of your time writing instead of doing ancillary things.

~~~
goldenkey
Wordpress is a development stack that happens to have a
Page/Post/Categories/Tags schema system. It is much more than a "blog."

It sounds like you didn't know how to secure your server with at least chroot
jail, selective port filtering, and njinx injection filtering or apache
fail2ban.

I have been running multiple wordpress sites for years and have never had
issues. These sites have custom themes I wrote to take advantage of the wp_
apis, to do much more than just blogging.

For example: [http://gregoryscoffee.com](http://gregoryscoffee.com) is done
entirely as a custom wordpress theme. The different coffees are actually posts
in the Coffees category - their thumbnail is fetched by grabbing the image
attachment on each of the posts. In fact, all the dynamic content is stored as
posts. The owner has no problem updating the site, since it is all editable in
the normal wordpress admin.

~~~
vickychijwani
> Wordpress is a development stack that happens to have a
> Page/Post/Categories/Tags schema system. It is much more than a "blog."

This discussion is about blogging, so IMO it's a valid comparison. While WP
can be used for a whole bunch of other stuff, that doesn't change the fact
that it's one of the most popular blogging platforms.

> It sounds like you didn't know how to secure your server with at least
> chroot jail, selective port filtering, and njinx injection filtering or
> apache fail2ban.

Well, I shouldn't need to know those things if all I really care about is
blogging.

------
pvsukale3
I am a jr web developer. I attempted learning Android app development using
java but gave up because it felt too complicated and hard to me as compared to
web development. Last week when Google launched its flutter beta I reinstalled
Android studio and worked through basic app development tutorials in their
website. Dart feels cool and I feel like I can build something cool without
making it too complicated. This is just my opinion but I might be wrong too as
I have no experience with developing native apps.

~~~
s73v3r_
I honestly cannot grasp this idea that Android dev is more difficult than web
dev. Especially when, to get started with Android, you just download Android
Studio (1 tool). To get started with web development, you have any number of
competing or complimentary or overlapping tools, the combination of which
seems to change every week.

~~~
vanilla_nut
I agree coming from the perspective of somebody who has a computer science
degree and 5+ years of C-style language experience... but maybe you should
consider the learning curve here for somebody who only has experience with web
dev. Getting used to typing, compilation (though I'd argue Intellij makes this
mostly invisible, and akin to a linter), not having the DOM (and getting used
to Android's XML layout system instead), strings.xml, and other shenanigans
would make things hard at first.

I think if you want to make a lot of relatively small projects, web dev might
be easier for a while. But as your projects start to scale up in size, having
proper inheritance, compilation, a type system, etc. has growing benefits.

------
bane
At some point, Google is going to screw up. This will create business
opportunity for anybody who's put a few years and a few hundred million into a
strategic replacement. Android is already creaking at the seams in certain
places, it won't be a huge surprise if some use-case comes along that
invalidates enough of the platform that Google will have to replace it.

Don't forget, among the companies that are sinking money into replacing
Android is also Google. They're preparing for a fight.

Times when OS's were fundamentally replaced because of industry paradigm
shifts:

\- Unix -> Linux

\- MS-DOS -> Windows

\- Windows 3.x -> Windows NT

\- ProDOS -> GUI ProDOSs

\- Android with a Blackberry clickwheel interface -> Android with a
touchscreen

\- Windows CE -> every other mobile platform

\- Mac OS -> OS X

\- OS/2 -> Windows NT

\- CP/M -> MS-DOS

and so on.

~~~
adventured
> At some point, Google is going to screw up.

Microsoft screwed up on numerous occasions with Windows. Once the monopoly was
in place, that simply didn't matter so much. Consumer behavior reinforces the
monopoly even in the case of screwing up: people very aggressively stick with
what they know. The same will be true of Google-Android.

Getting consumers to switch is extremely difficult. Competing with Android is
extremely expensive. Delivering your Android killer at exactly the right time,
with a vast improvement over Android, with the right marketing hit, with the
right partners, with the right hardware - good luck, it's not going to happen.

~~~
ksk
All true, but Microsoft (until very recently) had never tried to grab 30% (or
w/e it is) of their platform's revenue through an app store. They bent over
backwards for the developers by keeping old obsolete broken apps working on
newer versions at zero cost to developers.

If I as a company was forced to give 30% of my revenue to Google (or apple or
ms), you'd best be assured that the most important thing, long term, is to
make sure I get 100% of my sales. That is a very important carrot that you can
use to get developers to switch - and as you alluded to, its just one piece of
the puzzle.

------
yla92
> The irony being that most of the big shops are aggressively dumping it in
> favor of Buck — Facebook’s Android build system. Google is chasing a dying
> strategy here.

Igave it a try to a "small" project and there weren't any noticeable advantage
over Gradle (and given that Instant Run is working quite well, it was really
buggy when it comes out).

I know for a fact that aside from Facebook, Uber uses it and comes out with a
nice Gradle plugin for Buck called OkBuck[0]. I wonder what other big shops
use as well. And I would like to know if anyone here has used it and saw any
dramatic advantage over Gradle and worth investing time integrating Buck into
current projects.

[0]: [https://github.com/uber/okbuck](https://github.com/uber/okbuck)

~~~
merb
Well Google has their alternative to "Buck" aswell, called Bazel:
[https://docs.bazel.build/versions/master/tutorial/android-
ap...](https://docs.bazel.build/versions/master/tutorial/android-app.html)

~~~
izacus
Internally Google doesn't use Gradle at all (never did) so I have no idea what
the author tried to tell with his paragraph.

The fact that iOS is successful without a comparable build system (everything
is bound to Xcode projects and tooling based on that undocumented changing
format), makes me think he's overestimating importance of the build system.

~~~
vorg
> overestimating importance of the build system

True. Gradle (and its Apache Groovy build DSL) conquered a market by first
creating that market. There's really no need for a build system with a
procedural build language -- a declarative language to describe a build like
with Make and Ant/Maven is good enough.

~~~
HillaryBriss
my recollection from the days of the Eclipse plugin is that building from a
command line and building from the Eclipse plugin were two separate pathways.
you could get a different apk building through the IDE than through some CI
system running the build from a command line!!

so, they addressed that pain point by using Gradle, which also did dependency
management really well (compared to say Ant and, many would argue, Maven) and
by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.

~~~
pjmlp
They could have sorted out that problem by using Maven and improving their
Eclipse plugins, just like tons of Java developers do every single day.

Instead someone at Googleplex managed to steer a team to rebuild the world to
their favourite IDE and in the process reboot the whole Android development
stack, which by the way is still not done.

Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion
not been released and to this day there wouldn't be a solution how to use the
NDK inside Studio.

I bet Google IO 2018 will again have a talk about how to improve Android build
speeds.

~~~
izacus
Pretty much anyone not insane these days is switching to the IntelliJ stack.
Eclipse development is dead in the water and lagging behind more and more.

~~~
pjmlp
I am yet to use InteliJ professionally, specially given that it requires more
beefy computers than Eclipse.

Indexing that one cannot turn off unless laptop mode is enabled, spinning the
HDD all the time, really?

Also none of our customers IT teams allows InteliJ on their leased
hardware/VMs to external partners.

The exception being Android Studio.

------
eudora
> I am talking about full-scale replacements for Google’s entire Android
> development stack. Microsoft has Xamarin, Adobe has Cordova, Facebook has
> React Native, I mean it’s crazy town. [...]

> It’s like everyone who’s ever tried to do Android programming gave up and
> declared: “This is so bad that I will do my own startup to make it better.”

> And Google, not to be outdone by their competitors, responded by saying, “Oh
> yeah? Well you can’t compete with us, because we’re going to compete with
> us!” and they launched Flutter, which is — I am not making this up — a 100%
> serious Android development stack that competes with native Android, and
> whose existence the actual Android team simply refuses to acknowledge.

This is incorrect. Every one of these I've heard of (all the big ones) and
probably the rest don't exist because Android development is so terrible, they
exist mostly to facilitate one codebase for both iOS and Android, or to allow
the use of a different language.

I mean, that's incredibly obvious, so I don't know why he's got this here.

------
digi_owl
None most likely. The closest we came was when Amazon unveiled their Fire
variant. And the Google response to that was to move development of anything
user facing out of AOSP.

Compiling AOSP today will result in something that look and behave not much
different from late 2.x Android.

~~~
kshingne
\-->Compiling AOSP today will result in something that look and behave not
much different from late 2.x Android.

Any examples?.As a developer, the one's I think of are location apis (still
available in the AOSP, but requires much more code to get right than the
google play services version). And the look and feel does not depend on the
play services sdk.

~~~
kuschku
Before Android 2.3.7, AOSP included Google Search, Google Books, Google Talk,
the Android Music app, the Android Launcher, Settings, Contacts, Calendar.

In Android 8.0, AOSP does not include any of these anymore.

In Android 8.0, you need to use Google Play services to get Location,
Stepcounter, any device sensor, recent TLS on pre-8.0 devices, any of the
above apps, background job scheduling (the new JobScheduler only works on 8.0
or Google Play services), and so on.

I've written apps that don't rely on Play Services, I had to reverse engineer
and clone half of Play Services to even get a semi-working version.

Nowadays, the source code of a new Android version is released _months_ after
the binaries are released, and over half a year before the first binary beta
releases are released (Android P's first beta binaries are out today, the
source code is expected in december).

You can already build apps for Android P, making use of the new features - if
Google gives you the required code, which they only provide to themselves and
a selected few developers.

Google makes it as hard as possible to compete fairly, and this has already
caught the attention of the EU.

And then, of course, there's the fact that the Chromecast SDK requires Play
Services (so you can't use Chromecast on Kindle devices), and that receiving
Chromecasts is even entirely impossible at the current time for non-Google
devices (these are the reasons why Amazon doesn't support Chromecast, but is
instead together with Netflix trying to establish a cross-platform API that
can use Amazon's sticks, Miracast devices, Chromecast, and many other
devices).

Google has done everything they could to be as anticompetitive as possible,
and of course this will lead to legal action. Potentially half of the Android
ecosystem at this point may be based on criminally anticompetitive actions.

~~~
FreakyT
It's pretty sketchy, yes, but it seems to me that Apple has always done even
worse equivalents to those things. When will the EU hammer come down on them?

~~~
ocdtrekkie
There's a few reasons Apple doesn't run afoul of the law as often as Google
does:

\- Anticompetition law applies to monopolies. While Google has several
products or services with over 80% market share, Apple has none. Apple's
highest share of iOS is in the U.S., where it rolls around 50% with Android,
but globally, they barely make an appearance on the board. EU's
anticompetition law has no interest in a phone platform with less than 15% of
the market.

\- Apple tends to make a lot of things proprietary, but they're also only used
by them in the first place. iOS only runs on iPhones. Google gets into a lot
of additional trouble by exerting it's control over it's OEM "partners". For
instance, bundling it's Google Apps together as a requirement for OEMs is
definitely illegal, whereas Apple putting it's own apps on it's own devices is
not.

------
TuringNYC
I appreciate having multiple players in the marketplace, it creates healthy
competition and keeps progress brisk. My bigger fear isn't someone else
stealing Android from Google, but _Google stealing Android from Google_ (e.g.,
via insufficient investment, insufficient maintenance, confusing strategy,
etc.)

There are many examples, but some that come to mind are Google letting Google
Voice near-die via insufficient maintenance/investment. Or Google literally
giving away the opportunity they had in capturing chat (via Google Chat) due
to a confusing strategy (Google Chat/Hangouts/Duo/Allo/app-of-the-day)

~~~
gman83
They're literally going to do this with Fuchsia I predict. ChromeOS is there
too already the tablet space is confusing.

------
royjacobs
Isn't the whole point of these competing stacks not to provide an alternative
to Android but to provide an alternative to _all_ phone OSes? The idea being
that you can write your application 'once' and it will be available on Android
and iOS (and, as a comedy option, Windows Phone I guess)?

If you look at these toolkits in that light then their existence is justified
without it being a nail in Android's coffin, so to speak. Not that the
underlying tooling can't be better, but devs are moving towards cross-platform
toolkits precisely because they are cross-platform, not because Android is
terrible.

------
chickenbane
I doubt anyone will steal Android from Google. I can see two scenarios where
the Android SDK (which includes Kotlin, Java, NDK) + Google Play Services is
really threatened:

1) the WeChat scenario. Amazon is probably the best positioned so far and
their platform and services are also available on iOS and Web. The potential
WeChat could avoid the Google tax by handling payment, but would likely have
to offer many of the Google Play Services (notably voice recognition, maps,
and location) so Google would likely still be involved (also e.g., GV invests
in Lyft and Uber).

2) Future OS includes Android compatibility. Another platform that can also
run Android (and therefore has Google Play) apps isn't really a loss for
Google, but it is a way for Android to be commoditized in favor of another.
Steve is betting on Amazon, but Samsung is probably the most successful with
their store (which doesn't seem very successful). If anything Google itself
has the advantage here - they mostly have it working on ChromeOS and I'm
willing to bet Android compatibility with come to Fuchsia.

------
nareiber
My android experience is limited, but these aren't android replacements.
They're replacements for creating native android apps. They usually throw on a
few, if not ten, megabytes of libraries and glue to get them to work on the
respective os/framework they are landing on. Download size still matters
outside of metropolitan areas, and performance is always important.

------
skybrian
I'll just point out that Flutter has hot-reload as well. Maybe someone could
do a comparison with React?

------
zengid
> _For business and productivity apps, React Native offers reasonable
> performance, cross-platform compatibility, incredible tools (the best being
> from Microsoft. Hello, relevance! Welcome back!)_

When he says Microsoft has the best tools for React Native, does he mean
something like ReactXP [0]? Or Does he just mean Visual Studio Code?

[0]
[https://microsoft.github.io/reactxp/](https://microsoft.github.io/reactxp/)

------
YaxelPerez
Isn't Google developing Fuschia OS to replace Android and Chrome OS?

------
yazr
Completely off topic - but is the Android Gradle builder fully open source, or
does it contain specific binary-only components ?!

(i.e. can i build the builder itself from source code ?!)

------
angryasian
This mainly sounds like a rant about cross platform development between IOS
and Android. I mean couldn't these same arguments be used to justify using RN,
or flutter, or etc.. over developing IOS native. I'm sort of missing why he's
pointing to Android directly. The main issue is there are two major platforms
and like he said people don't want to develop things twice.

~~~
brandmeyer
I think you missed the parts of the article where he complained about API
churn, high latency edit-test cycle, and device compatibility.

------
z3t4
Google is saving billions by not having to pay for being the default search
engine in Chrome and Android.

------
braderhart
Vulkan and Wayland are going to steal Android away soon, because you will no
longer need it.

~~~
gregknicholson
Seriously though, I'm glad I'm able to opt out of all this channelsy
advertising-at-me business. I don't want to be a consumer in this market. I
just want communication tools.

I'm looking forward to receiving my Librem 5, and I'm pleased Lineage
continues producing phone software intended for users, not advertisers.

------
ozten
This conflates Android the operating system with Android's SDK. Let's say
ReactNative wins and developers create apks that are mostly ReactNative...
Google still wins. They don't care what an App is written in and customers
can't tell either.

Android the OS is pretty safe, as cyanogen.com valiant run at Google from this
angle proves out.

~~~
coldtea
> _This conflates Android the operating system with Android 's SDK. Let's say
> ReactNative wins and developers create apks that are mostly ReactNative...
> Google still wins. They don't care what an App is written in and customers
> can't tell either._

Which means other vendors can far more easily keep all their apps and move to
a non-Google controlled mobile OS of their own.

~~~
HillaryBriss
I hear what you're saying, but how much more easy does this make it to move to
a non-Google OS?

The thing is that with Google Play Services libraries and the Google Play
Store, Google has a really strong lock on a huge collection of apps out there.

Using something like ReactNative on top of that stuff kind of seems like a
baby step away from Google, but there's still so much Google control to
eliminate.

------
HillaryBriss
Another great, highly opinionated, but still great, Yegge post.

My favorite quotations:

1\. "Android’s dev stack is the world’s biggest poo sandwich"

2\. "And Android? Yep. It’s the biggest poo sandwich of them all."

3\. "...there are two Android APIs for getting mouse-click events on a
scrolling list, but one of those APIs doesn’t work on LG. I mean come on."

4\. "I love Kotlin; it’s the future of Java. But let’s face it: It’s not where
the mobile market is headed. "

5\. ... the Android org at Google is not sure whether cross-platform is good
for them or bad for them, but that they are leaning towards “bad”

6\. "most of the big shops are aggressively dumping [the android gradle build
system] in favor of Buck — Facebook’s Android build system. Google is chasing
a dying strategy here."

7\. "guess who else is making a big play with a competing [android app] store?
You guessed it: Jeff Bezos"

8\. "if you’re locked in a fierce competitive race ... and need to launch
faster, you should probably go with something other than Android Native ...
Among the cross-platform options, React Native is looking like a winner"

9\. "there are a lot of big sharks circling the Android boat. Google needs to
be careful."

