I take this blog post to mean that Play will provide WebAPKs to competing browsers and that I'll be able to install other stores on my Pixel.

Do I have that right?
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:

One quick point and then a longer one.

Quickly, the distance between Play's mission and Google's mission has always been both obvious and disappointing.

So why does it persist? To grok that, we have to understand the origin stories.

Play exists to extend a patina of safety over Android's (dangerous, dead-code-walking) foundations:


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

Keep Current with Alex Russell

Alex Russell Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @slightlylate

8 Jul
There's a lot of cultural rot packed into this and, per usual, California's *messed up* land use and tax policies are the backdrop.

To recap: Prop 13 means housing gets cheaper the longer you hold, not just 'cuz feds subsidize mortgages, but also property taxes.
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.

How bad is it?


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.

But the path to that is brutal.
Read 12 tweets
23 Dec 20
Even the truth in the original demonstrates ignorance: front-end (and client-side generally) has layers to occupy you for multiple careers!

Codecs, databases & storage, graphics (2d & 3d), languages & runtimes, fonts & layout, networking, performance: all harder on the client.
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.
Read 5 tweets
13 Oct 20
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.

[1] infrequently.org/2020/09/the-pu…
[2] macworld.com/article/357533…
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:

Read 7 tweets
14 Sep 20
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.

This is a choice.
Read 8 tweets
17 Aug 20
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...
...backpressure for sockets, web transport, web codecs, WebGPU when it's ready (not when Apple deigns), payment handlers, etc. etc.

🍎 has used control not just to curate the store but also prevent the web from being a viable alternative & it's a goddamned scandal.
"oh, but feature X is in a tech preview" is the new "believing FB when they say they have 'more work to do'".

At some point you have to look at the pace and trend and conclude that not allowing other engines is strategic.
Read 4 tweets
19 Apr 20
I don't usually do this, but it's about public health and this site is getting a lot of press and HOLY !*#$ WHAT IS WRONG WITH THE REACT COMMUNITY!?:

This feels like the right place to invoke @tomskitomski:

If I had to guess, this probably wasn't ever tested on anything w/o a "Designed in Cupertino" badge.
It's *more than 900K of JS* to see the headline data. A screen shot is significantly smaller.

Nothing about this is OK.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!