My contention for something like a decade has been that if your tree is closed for half the year, you're "kept source", regardless of the license code eventually drops with:
Android exists to put a search box in everyone's hand w/o Apple's usual highway robbery.
To the extent that both of those things are, at a surface level, going well, nobody asks harder questions.
That Play is simply Apple App Store Lite, skating by on being *slightly* less terrible to developers (at some cost to users) is not seen as a problem to be solved.
Consider what Play ~is~: a search engine that doesn't actually get you answers, because the corpus it is designed to project into the world *is fundamentally unsearchable*.
Remember Now On Tap? Android App Indexing? "Deep Links" (or as we call them on the web, "links")?
The shift in use from web to native happened slowly, and always in the shadow of a competitive, more closed threat.
There's real value in living to fight another day, FWIW, and it wasn't always crazy to think being more open was enough.
Hiroshi's blog post (or rather, the Play PM's blog post that Hiroshi had to sign) rings hollow because it's the self-serving, unquestioned and unlititgated assertions that have been able to win an internal dialogue for something like a decade.
They work less well in public.
Not everyone is locked in a struggle with Apple for share. Some folks -- most folks, even -- just want safe computing they can have some agency in.
Android's core kernel distribution process is rotten, so Play has too much power in the name of safety.
There's a better way.
We *can* have meaningful choice in apps and runtimes without high app store tax rates.
How? We need safe-by-default runtimes and platforms.
Today, that's browsers. They're built to a more paranoid standard.
This is why browser choice and capabilities matter so much.
So, if Hiroshi et. al. want to raise the bar for safe, effective, open mobile computing, they have the power to do that. They can put in place Play policies that promote meaningful browser choice, and help ween Google and the rest of the ecosystem off of dark patterns.
Doesn't require new OSes (which Android can't make real in less than hardware-replacement timescales anyway), and doesn't need tenuous whataboutism to justify.
Just make Play web friendly and start to discourage the over-powered, insecure native side of things.
Would this mean dramatically shrinking the set of superpowered apps to several dozen browsers and a much smaller set of native apps held to a higher standard? Eventually.
But it would also mean safer, faster, less resource hungry, more open computing w/o higher taxes.
Hiroshi's post is Native Apologetics. It's an argument about why a bad world that's antithetical to Google's own best software values should persist.
It lands with a wet flop because the lived reality simply doesn't back it up.
An important PS:
The Android team is *rightly* afraid of sideloading and dodgy stores. They're bad, and do an even worse job of papering over Android's terrible security story than Play does.
Giving developers everything they want isn't a better world (see also: WinXP).
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Combined with now-rampant NIMBY-ism from the last generation to enjoy tax-funded higher ed, spiraling property costs mean the dream of owning a reasonable home and starting a family is a receding vision.
The "way up" is "supposed to be" tech -- one of the few industries often paying enough to get you a slice of California. And for the lucky few, it absolutely is.
It *is true* that working across layers is a key trait of highly effective engineers. Respecting those who do it on the client is good.
The idea that one must "graduate" to the back end carries the same stench as every overconfidently presented "full stack" failure I trace.
Front-end demands humility because it is *different* and, in key respects, *harder*.
There's an asymmetric hubris here: those of us who work the client don't tell back-enders that their work is trivial. Nor do we gate-keep the "full stack" crowd, no matter how poorly they do.
The cognitive dissonance of anti-web and anti-choice rules made & justified because device resource scarcity [1] against the marketing of ALL POWERFUL CPUs [2] is dizzying.
For a sense of scale, when the anti-choice, anti-web rules were laid down, Apple's fastest device was the iPhone 3G; a single-core, 32bit, in-order, ~400MHz chip attached to 128MiB of system memory.
Today, the slowest device you can buy directly from Apple is based on the A12...
The A12 is a 64 bit, 6-core, 2-and-change-GHz part with ~~8MiB of L2 cache~~ attached to 3GiB of RAM in the most resource-impoverished device Apple markets today:
Trying again: Apple's iOS store shenanigans include a subtle & unique catch-22 journalists should grok:
- when apps violate policy, Apple says "use the web"
- ...except every iOS browser is required to use Apple's engine...
- ...and it's Apple keeps it year behind
This is hidden from view because no iOS browser maker dares to submit a browser that shows a "this isn't _real_ Firefox" (e.g.) banner...because what is the user supposed to do? Buy a new phone? They also can't afford to be cut off from all the world's rich users.
But why is Apple's engine & browser years behind?
Because Apple doesn't fund the WebKit team with anything like the headcount they'd need to keep up. And let's keep in mind that this isn't down to some sort of cash crunch.
Now imagine a world where Apple hadn't cut off the web at the knees and the things we regularly do on Android were possible, e.g.: WebGL 2, WASM threads (soon), Audio Worklets, large media storage, prompted PWA install, push notifications -- not to mention the upcoming stuff...