Hacker News new | comments | show | ask | jobs | submit login
Who will steal Android from Google? (medium.com)
183 points by aberoham 6 months ago | hide | past | web | favorite | 158 comments



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.


You overestimate how hard it is. Amazon did it, and the entire country of China did it out of necessity. As Amazon's ecosystem gains steam, there will be enough third party replacements for Google's apps that it will be easier for others to switch too.


When are you seeing Amazon's Android ecosystem is gaining system? All they are doing is building their own apps on top of their implementation of Android. The rest of the apps are just being ported over from normal Android.


Amazon's phone might have flopped, but they've eaten the Android tablet market. Google tried to make a "pure" android tablet with the Nexus 7, Nexus 10, and Pixel C. The 7 was the only one of those with any success, and it's long gone. Tablets are either iPads, Surfaces, or Kindles now.

I don't know what Android tablet would be in next place after the Kindle. If you count big phones with styluses, probably the Galaxy Note. I know the Samsung Galaxy Tab line exists but I've literally never seen one.


I think at least part of the death of the Nexus 7 is because Google seemed to have no interest in refreshing it. I was looking to upgrade mine a while back and the only thing available was the same old tablet.

Google has a weird relationship with consumer devices. They release stuff, then seemingly completely abandon it for years. I don't know what exactly their goal is with some of these devices, but if e.g. Microsoft did the same thing with the XBox, they would never be where they are now.


> Google has a weird relationship with consumer devices. They release stuff, then seemingly completely abandon it for years.

I always get the impression that Google doesn't want to be in the consumer hardware market, they want to be making software and online services supporting consumer hardware. They participate in the hardware market to drive the market in the direction they want it to go, but really want third-party hardware partners to do the heavy lifting on consumer hardware.

> I don't know what exactly their goal is with some of these devices, but if e.g. Microsoft did the same thing with the XBox, they would never be where they are now.

Their goal seems to be to become what Microsoft was with the PC market, only in more markets and with a bit more active hand in steering the hardware markets.


> I think at least part of the death of the Nexus 7 is because Google seemed to have no interest in refreshing it.

Yup. It was the right size (can fit in a pant or suit pocket!), it did everything one could want, and it worked just fine. Of course Google killed it.


> They release stuff, then seemingly completely abandon it for years.

It's not just with devices. The most obvious place this happens is with IM services. Whether it's intentional or not, maintenance of existing products seems to be frowned upon within Google since promotions are mainly based on releasing new products.


> I don't know what exactly their goal is with some of these devices,

I always assumed google's hardware stuff was basically a reference implementation. When traditional manufacturers 'get it' google steps aside.


This was definitely meant to be the case in the Nexus era, but the Pixels are heavily marketed widely to consumers, and are given features that are withheld from OEMs for a while. Especially with their push to branded accessories like the Pixel Buds and the like, I'm pretty sure the Pixel line is supposed to be their iPhone, a mainstream, consumer-friendly brand.


With their update policy their are certainly not iPhone consumer-friendly like.


> Amazon's phone might have flopped, but they've eaten the Android tablet market.

What? Kindle Fire initially did really well, and Amazon was briefly no. 1 in Android-ish tablets and no. 2 in tablets behind Apple, but they’ve lost marketshare and others (mostly Samsung) have gained, largely on the back of the official flavor, rather than AOSP-derived versions like Amazon's, of Android.

> Tablets are either iPads, Surfaces, or Kindles now.

This would be closer to true (and in order of sales from most to least) if you said “Galaxy” in place of Surface.

> I don't know what Android tablet would be in next place after the Kindle.

Samsung sells more, in total;Amazon may have the highest selling individual model of tablet powered by an Android or Android-derived OS, but they don't sell the most devices.

> I know the Samsung Galaxy Tab line exists but I've literally never seen one.

I've literally never seen a Kindle Fire, and I saw three Galaxy tablets before I left my house this morning. But that's just anecdote, the more relevant thing is marketshare reports, and while different reports have the figures differently (and often breaks out only by vendor and not OS, and makers like Samsung have more than one tablet OS since convertibles are usually counted), but consistently across reports Amazon is significantly behind Samsung in tablets, e.g.:

https://techcrunch.com/2018/02/06/apple-continues-to-dominan...


>the more relevant thing is marketshare reports

Looking at that IDC report, you'll note that Samsung is at -6.4% year over year for 2017. Amazon is at +30.0%.

If you look just at Q4, Amazon was in second place behind Apple (with Samsung in third), at +50.3% year over year compared to Samsung's -13.0%.

Those numbers do not indicate to me that Samsung is doing well in Android tablets. Granted the Samsung tablets are much more expensive than a Kindle Fire, so you'd expect it to be low, but the year over year downward trend is not impressive.

https://www.idc.com/getdoc.jsp?containerId=prUS43549518

EDIT - also note that the Galaxy Tab S3 (I think this is the current version?) is still shipping Android 7. Apparently Android 8 support is in development, but "it's going to be a while."

https://www.sammobile.com/news/galaxy-s7-galaxy-a5-galaxy-ta...

Bummer about Google's official tablets, they were better about software updates. The Pixel C (released at the end of 2015) got android 8 but will not get 9. Still, that was pretty good by Android standards.

Re: Surfaces, I'm probably overestimating these because I see them in professional use. They're pretty expensive to get much consumer traction.


Also, you can look at Tablet Marketshare here: https://www.statista.com/statistics/276635/market-share-held...

Granted Amazon is big but Android tablet marketshare as a whole (exclusing Amazon) is much bigger. I would use data to back your assertions vs. what I am observing (as that is subject to echo chamber and confirmation bias risks).


A few weeks ago, I wanted an Android tablet to play games. I shopped around for low end tablets, the the options all looked like the same tablets that were on the market 3 or 4 years ago. Many ran Androird 4.x,or 5.x. Didn't Android 5.x come out in 2014?

I ended up buying one of these: https://www.simbans.com/tangotab.html. So far it's OK.


I think the challenge for Google is that they have a release culture more than a product line culture. So some group in the org is really proud of releasing, Android Wear, Pixel C, AR Kit, Chromecast, Daydream, etc. They get the kudos for doing it and move on to releasing something else. So Google has products that are sometimes really compelling. But they don't execute a road map for them and they languish.


Yes - Amazon has done well in tablet space but that isn't because of Android.

Most of the things that sell Amazon Fire are its really cheap price (it is probably a loss leader), seamless Amazon's Kindle and Content integrations (such as Prime as well as FreeTime). However, there are no Google Apps on it - no maps, no gmail, no Youtube etc. It is a really hamstrung experience if you have used their product.

Android is much much bigger than Amazon tablet and to say Amazon is eating away at Android is a disingenuous statement.


> Amazon's phone might have flopped, but they've eaten the Android tablet market

That is very country specific, I hardly see any Kindle that isn't a plain e-book reader around here.

What I see on my train travels is people using iPads or Windows 10 tablets with detachable keyboards.

Anecdote data, take it as you wish.


Well, it's gaining "steam," not "system," but I see it here:

https://www.npd.com/wps/portal/npd/us/blog/2018/with-homepod...

  day one pre-orders of HomePod were higher than all other
  smart speaker first day pre-orders, except Amazon’s Echo Dot


Thought exercise: Would Amazon be / have been better off maintaining their own not-quite-compatible version of Android? Or would they have been better off cloning and commoditizing Apple’s development ecosystem?

Higher up-front cost than a cheap fork of Android, for sure... But how much? Especially if they could manage to make a native development ecosystem that was plausibly competitive to Apple’s, but allowing for easily targeting Apple’s devices as well, I could see this strategy being a better way to stave off competition from third and fourth players.

There’s prior art on cloning Apple / NeXT APIs and whatnot. Surely a company with the heaft of Amazon could do at least as well as the small open source efforts.


Not many of them. Things like Maps, for example. Unless you're targeting one of those Chinese devices without Google Services, you're going to use Google Maps, because that's what almost everyone has on their phone. You're not going to spend the resources basically doing the same thing twice with another Maps provider.


Best candidate is some Chinese OEM or tech titan like WeChat that has already done all the insane work it would take to replace the things Google holds hostage. Wouldn't necessarily be more open if it's WeChat, though.


Of course if google actually tries that there is an anti-trust lawsuit awaiting them, which will probably force google to spin off android. (this may require a change in US presidents but that happens all the time)


> any company who wants to exclude Google puts their entire mobile product line at risk on this play

With the exception of China Inc. No place for Google so far.


True, but that's solely because Google chose not to do business there. They left that opportunity open to other companies, which is why it's the only place competition really exists.

That being said, while a Chinese manufacturer could try to branch out into the international market, that hasn't been working out for them so far. Huawei and Xiaomi have both pushed in that direction, but beyond limited success to begin with, now government entities are discouraging Chinese brands due to perceived cybersecurity risks. Whether those risks are overblown or not, it has severely hampered these companies' ability to branch out to the international consumer.


And even they put Google services in their global ROM's. At least Xiaomi does


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.


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.


> (or intentionally interfere by blocking YouTube access, similar to what they did with Windows Mobile, and now Amazon's Echo and Fire platforms),

Nice spin there! Youtube was blocked on Windows Mobile because Microsoft blatantly blocked all the ads in violation of policy. If Microsoft was in the right here, we would have seen a lot more aggressive posturing from them instead of silent retreat.

And for Amazon, it was a reaction to Amazon's decision not to sell Chromecast (and Nest devices). Amazon's excuse is that Google changed Chromecast APIs, which smells weak when you see other supported apps on Chromecast from Netflix, HBO, ESPN etc.


If you look at the totality of the evidence, even in that one story (where Microsoft then built the app to Google's specifications, with ads, and then Google waited until they released it before blocking it again), the story looks so bad against Google that even some of the reasonable press was starting to notice and report the issue as Google toying with Microsoft.

Here is a link to an overly-well-sourced comment I wrote on this:

https://news.ycombinator.com/item?id=14835776


At this time, Microsoft were also threatening Android vendors with a confidential list of patents (to prevent Android work-arounds) - MS leveraged these patents into a Windows Mobile deal "settlement" with Samsung. For a long while, Microsoft made more money from Android (patent license fees) than from WinMo.

Why would anyone expect Google to handle Microsoft with kid-gloves in this bout of corporate-combat when Microsoft was playing to win? You don't bring a knife to a gunfight.


You are definitely applying your own spin, to be sure. ;) Microsoft tried repeatedly to work with the YouTube team to comply with Google's ToS, but it was a moving target, Google kept changing their requirements until it was largely impossible to comply.

The Amazon/Google spat goes back a lot further than that, which I've talked about a bit in other comments here.


"or intentionally interfere by blocking YouTube access, similar to what they did with Windows Mobile"

They killed the Microsoft YouTube client because it didn't play by the rules regarding showing ads or downloading videos.


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.


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.


This is the ultimate in revision. Windows phone was incredibly laggy on similar hardware to Android.

I assume it was related to the inefficiency of the Windows kernel compared to Linux.

http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w... "I Contribute to the Windows Kernel. We Are Slower Than Other ...


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


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.


I don't know if you ever used a decent windows phone. But I can tell you that my Lumia 1020 was way more stable, smoother and user friendly than my Samsung Note 5.


The Lumia devices I have here are the living proof that isn't a myth.

I have never seen an 150 € Android devices that were as fast as they are.


What? MS blocked ads and facilitated stealing from YouTubers. Do you honestly support this type of behavior?


That iPhone is behind the curve on hardware specs is not really true. Their CPU+GPU is faster than anything else on the market.

And in terms of other hardware (RAM, camera, sensors) I would still say it's arguable


Actually the iPhone is only "behind the curve" in adopting new form factors. Regarding CPU and GPU power, camera quality, and new sensors and stuff, the iPhone has always been the machine to beat.


iPhone is generally behind the curve when it comes to hardware specs

Really? In all the benchmarks I've seen, the latest iPhones handily beat the latest Android phones. (And old iPhones remain usable longer than old Android phones.)

Assuming the software doesn't get in the way, benchmarks are all about hardware, not software.


The numbers on the box may be lower (number of cores, ram size), but I agree, benchmarks usually show iPhone very competitive or in the lead.


Given that those benchmarks running on operating systems, the software(OS) matters. >And old iPhones remain usable longer than old Android phones. It depends which Android phone you are comparing with. If you compare with a flagship, it should be head-to-head. But i think that is because of stability/efficiency of iOS over android.


Given that those benchmarks running on operating systems, the software(OS) matters.

No, if the OS significantly slows down a benchmark, it's a bad OS. Both Android and iOS are fine in this respect. (It's a bit fuzzier for graphics tests, I admit, where driver quality comes into play.)


> But i think that is because of stability/efficiency of iOS over android.

From what I understand iOS is pretty picky about background processes. Limit what can run in the background (and for how long) with android and you will probably get similar results.


I don't understand why you are all talking about software and the OS. My point was that for basic benchmarks testing things like CPU speed and storage speed -- the hardware -- iPhones tend to be ahead of Android phones.

A quick google search gives me results like this: https://www.tomsguide.com/us/galaxy-s9-benchmarks,review-519... "Galaxy S9 Is Fastest Android Ever, But iPhone X Is Faster"


I couldnt immeadiately find a graph or data but potentially parent was talking about price v performance. The computer offerings historically have been behind the curve but I thought the iPhone performance was strong compared to the field. I would be happy to change my opinion with new information but I agree with you.


If by "generally behind the curve when it comes to hardware specs" you mean a generation and a half _ahead_, then yes.


iOS also seems to perform better with similar specs than Android.


Perks of not running everything in the JVM. Even though it's really fast at this point, it's still going to have more overhead than running apps natively.


Does it matter when half of the apps are based on Cordova or React Native, running everything in the JavaScript VM and majority of the games are based on Unity running exactly the same C++ and C# code everywhere. It's not like some calendar app will have major performance gains with native code.


Compiled code is faster than bytecode is faster than interpreters.

It's not always true, but it's a good rule of thumb.


It's long established that Java's problem is not the JVM or bytecode but it's memory model.

Java's bytecode execution speed in the JVM is good enough that it's on part with C, easily beating any language with even a slightly inefficient compiler, like Go or Haskell.


Are you referring to the lack of value types? Or is there some more fundamental problem?


That's a decent part of it, but also the fact that in Java:

  class A {
    B b;
  }
"b" will be a pointer, as opposed to "b" being contained within instances of class A.


Android does not run anything on the JVM AFAIK.


this. android phones only seem "better" because they have a buttload of cores (10 in some cases) with weak single threaded performance.


This is Nintendo's same strategy, I believe.


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.


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.


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.


You probably haven't seen one, because most of them are enterprise apps used by the employees, not something for the regular user.


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.


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.


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

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.


I hate being depended on Google and I tried hard to break its chains. I can't. Neither ddg, nor Bing, nor Yandex are anywhere close to Google search quality. I'm periodically trying them, but it seems like Google is light years ahead. And using Google Search is as integral to my work as using IDE, so switching to something like Bing is the same like switching to Notepad.


I haven't used Google in years. Haven't had an issue that Bing couldn't find that Google could. FWIW, you can use Startpage to get Google results without feeding the beast, or use the !g command when searching with DDG to get Google results.


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


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


Consider my view on bing changed.


They are selling it to B2B devs.

No flashy things but a lot of boiled goose.


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.


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.


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.


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.


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?


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.


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.


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.


I find the idea of Google going solely first party with Fuchsia super interesting/compelling as a narrative. Although I assume such would hasten other OEMs departure from Android nonetheless. It wouldn't take long until a given desired feature came first to Fuchsia, with Android "later".


Even I have high hopes for Fuchsia. It seems like it's doing a lot of things right from the ground level, particularly in terms of security.

But from a business standpoint, it's a huge risk. If Google wants to get OEMs to switch from an established, widely popular platform to a new one, they're going to need one heck of a big carrot. It's likely Google would retain more control with Fuchsia, since giving OEMs control of experience, security, and updates is largely responsible for many of Android's woes, and OEMs will be resistant to that.

Google may have a much easier time retaining it's control under Android than trying to push a platform switch, which could actually, lead to OEMs switching to a different company's platform instead.


To me, re-architecting the Google / OEM split benefits both (disclosure: I haven't followed exactly what they're aiming for with Fuchsia).

If it becomes possible to update to new Android features and security patches without breaking OEM overware, then OEMs no longer have to dedicate teams to rewriting their crap codebases.

Which means they can put all those developers on features instead.

Which is what they've always been interested in and (arguably) better at in the first place.


I'm also intrigued by Fuchsia, but it doesn't look like it's intended as a smartphone OS. Even if it was, without access to the Android app store it'll be no more successful than Windows Phone or any of the other upstarts (and something like a hypothetical Android emulation layer sounds like murder for battery life).


I don't think running an Android layer on Fuchsia would necessarily be a problem for battery life (it's not like you'd need to emulate a different CPU), although loading all the Android frameworks and services could be a RAM hit. And apps with native code excessively tied to Linux might be problematic on the Fuchsia kernel.

Some Chromebooks can now run Android apps; I wonder how that works out for the user in practice. (I haven't tried myself.)


The moment Google announces it's not going to update Android anymore everyone will start developing for Fuchsia with Dart, Go, or whatever.

Also, considering Chrome OS has an Android layer in there why wouldn't fuchsia be able to do the same thing? It should be more than enough as a temporary solution.


Is Fuchsia backwards compatible with Android apps?


It supports Flutter, which is one of the potential Android disruptors Yegge mentions.

They're both open source, so I wouldn't be surprised if someone built an Android server for Fuchsia though.


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.


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.


You are comparing apples to pineapples. Medium does one thing, while WP, for better or for worse, does anything you want. WP is not just a blogging platform, it's a development stack.


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


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


From a reader perspective (can't speak to distribution as the writer etc...), a Medium hosted post usually means that I'm not going to be bombarded with banners, ads, mailing lists etc.

I might immediately click out of it, but the barrier for me to click is lower initially.


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.


I have the same experience. I think this is important, and it seems a lot of people are overlooking the ease of Flutter especially compared to native Android. "It just works".

Being backed by Google should also aid it in API compatibility vs other cross platform frameworks who are always playing catchup with the native API's.

Static types, hot reloading, a solid library of widgets, native performance, "reactive" just like React.. seems like a win to me.

Regarding the points made in this post on front page today [0], I think Dart being an unsexy even "boring" language is a good thing, since it's so much like other languages new devs won't wast time with a steep learning curve.

From an evolutionary perspective this can help the platform catch on quickly.

[0] https://news.ycombinator.com/item?id=16561901


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.


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.


I don't think that Android dev is necessarily more difficult than web dev, but rather, the first few steps in learning Android dev are much bigger steps than the first few in web dev. It's a lot easier in web dev to get something working, build upon it, add tools, and learn about the complexity of the ecosystem in small steps. On Android, you are hit with that complexity almost immediately. Combine that with tutorials that are either out of date or completely fall apart the second you try to do anything beyond a Hello World app (that compatibility matrix sentence is very real), and you get the feeling that Android dev is much harder.


IME, it doesn't get much more complicated than web development. Even as fragmented as Android can be, it's nothing compared to the number of frameworks, build systems, scaling challenges, operating systems, browsers...


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.


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


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.


As for the Mac it seems we've come a full circle: Mac OS -> OS X -> macOS


For now, your point stands only from a naming convention perspective.

However, if iOS apps do come to the next version of MacOS, we might be on the verge of delineating Mac OS X and MacOS into truly-separate generations.


Actually it is more than that.

On the Mac culture, UNIX is only an implementation detail, most users don't care one second it is there.

Not even Mac developers, those that actually target Mac users, not using it as a workaround to avoid dealing with Linux/BSD issues on laptops.


> 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


Well Google has their alternative to "Buck" aswell, called Bazel: https://docs.bazel.build/versions/master/tutorial/android-ap...


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.


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


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

I don't know, Gradle allowing easy extensions allowed us to do continious delivery significantly easier than with Maven (not to mention iOS build system). It's not a must, but it's a really nice thing to have when you need to build several versions of a build, tag versions dynamically, build docs, etc.


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.


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.


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.


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.


Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated.

Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.

The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.

Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.

Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.


> Android uses Gradle as its default build system. It gets extremely slow on large applications like Uber, Facebook, Nest, Snapchat, etc. The enterprise customers all complain to the Android tools team about it, and they throw a ton of work into trying to speed it up. And it gets more and more complicated.

Sure, this is why it's adopting a structure similar to Blaze, Buck and others with smaller modules, not to mention sharded compilation with Instant Run. The whole reason for Blaze, Buck, etc. existence is that common build systems fail at huge applications used at Google / FB / Microsoft scale. And yet that doesn't seem to stop adoption of build systems like Maven, SBT, Gradle and all others which are used by vast majority of developers not working at GooAmaBookSoft scale.

> Meanwhile, Uber (their marquee Gradle customer) just switched to Buck -- I don't think Google even knows this yet.

Tools team is certanly aware of it.

> The build system in Android is a huge pain point for the dev stack. It's a big part of why things like React Native are gaining traction.

Not sure how second follows from the first. React Native is gaining traction because it lets developers quickly develop for two platforms at once (just like Xamarin, Cordova, Ionic gained a lot of traction in enterprise before). Instant redeploy is very nice but hardly a huge deciding factor.

> Your comparison to iOS is basically invalid/irrelevant, because iOS doesn't have the same legacy packaging issues (APK) as Android has. Android's build is actually quite complicated, more so due to the device proliferation, and it's getting worse over time.

Huh, lack of proper build system is a huge headache when doing iOS CI builds. The compiler is also comparably slow for Swift/ObjC (especially if you add just a bit of C++ code) so I don't know how can you just dismiss it. It has very similar issues and the adoption didn't suffer.

> Hope that helps. I'd be happy to answer more detailed questions about why it's so bad, since I've worked on it extensively in the past.

Not sure what you worked on (I'm guessing Gradle itself?) but it doesn't seem like you know all that much about building Android apps with Gradle in most companies out there.


> Instant redeploy is very nice but hardly a huge deciding factor.

I think you're wrong on this one. A large number of devs care about dev experience at the expense of other important things like platform maturity, reliability, and security.

I don't agree with many of Steve's points in his post, but I do agree on this point. Both factors - x-platform development and instant redeploy - have contributed significantly to React Native's success so far. Indeed, if it weren't so important, I wouldn't expect Google to invest as much time and money as it did in getting Instant Run to work correctly (like others said, it was buggy as all hell when it first landed in Studio's stable channel and only became usable after many months). The fact that Flutter advertises "stateful hot reloading" prominently is just more evidence that it's important for attracting devs.


And you haven't addressed the NDK, which is like life in the trenches of build systems.


I think of Instant Run as the "crash" button.


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


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.


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


I'm guessing the parent comment is referring to the state of the "built-in" Android apps.

Any AOSP app that has a Google app equivalent generally stopped being updated when that Google app equivalent was released. The AOSP music player was last updated for Gingerbread (replaced by Google Play Music), Gallery was replaced by Google Photos, the SMS app by "Google Messenger", the Mail app by "Gmail" -- even the Phone app is no longer updated!


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.


> In Android 8.0, you need to use Google Play services

I agree. This point is under appreciated. The GPS libraries and their backend services (e.g. Maps and Location, Push Notifications, Google Auth, etc) to a great extent ARE the android SDK.

I don't quite see how Yegge's use of the word "stealing" can be correct. No one can steal those backend services. A competitor is going to have to reimplement services like Maps and Push Notifications (not to mention the Google Play Store itself). And that just means more fragmentation in the marketplace, not stealing android.


Actually, this has been done twice.

Recently by the open microG project, and earlier by Amazon.

Reimplementing every Google Play service, bug for bug, bit for bit.

And Amazon did it (and microG is close).

This is what prompted Google's SafetyNet project, and Google changing Chromecast to lock out Amazon and open source projects.

Google did everything they could to prevent competition, and yet, they didn't succeed.


--the new JobScheduler only works on 8.0 or Google Play services

actually, it works on Android 5.0, thats the version it was introduced in.

-> In Android 8.0, you need to use Google Play services to get Location, Stepcounter, any device sensor, You don't necessarily have to go through play services for any of these. API's are available in the platform for all of them or can be replicated.

I think the possible anti competitive behaviour from Google(in Android's case) is forcing the OEM's to install their apps by default.and practically forcing developers to use Play services for notifications.


> API's are available in the platform for all of them or can be replicated.

All the sensors are only available to foreground apps, and only while they are running (at significant battery cost).

The only way to get aggregate data is through Google Fit or other Google APIs. I've tried.

> actually, it works on Android 5.0, thats the version it was introduced in.

There's three versions, but all either require modern Android versions, or Play Services. I detailed this on reddit recently.


> Android P's first beta binaries are out today, the source code is expected in december

That sounds a lot like distributing binaries of copyleft software without distributing the corresponding source. Of course, I'm sure there's a very good explanation of how it isn't that, because that would contravene the copyright licences and be all illegal and stuff.


Android is Apache 2, sadly. And while the kernel is GPL, most vendors distribute kernel binaries without source, and even years later, never publish the source.

A major part of the Android ecosystem is based on unspoken piracy of the Linux kernel.


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?


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.


There's no such thing as a 'monopoly on your own product' (e.g. Apple controlling 100% of iOS devices). That's just called "having a product".

You're a monopoly if you have a almost complete hold of the entire market, which Apple does not, for any market they are in.


Maybe when Apple runs 85% of the market and makes contracts with OEMs that have a noncompete clause?

You can only commit the crime of "abusing a dominant market position" if you have a dominant market position.


Apple has already gotten into hot water, but not about iOS.

They did get into trouble regarding price fixing of ebooks, for example.


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)


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


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.


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.


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.


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


> 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/


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


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 ?!)


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


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.


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


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


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.


(laughing emoji)


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.


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


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.


It's not as simple as you might think. If Android OS becomes the plumbing, and Facebook controls the developer experience, then it levels the playing field for a competing hardware/software platform (e.g. Windows). It makes it harder for Google to "control" the platform.

It's analogous to how the browser came along and turned the desktop OS into plumbing for a lot of people. My wife uses a Mac but she really has no idea that it's a Mac. She only uses the browser, so she could easily switch to Windows. Apple has really no hooks into her at this point, and that's an uncomfortable position for Apple (or any desktop manufacturer) to be in.

Google _needs_ to maintain control of the developer experience. In my opinion they should add a TypeScript option to Flutter, embed the v8 javascript engine into Android, and support Flutter with JavaScript as a first-class citizen on the Android stack. They should start this work yesterday.


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




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: