adb is a developer tool. You need a tethered and trusted computer to be able to transfer an app using adb, and you need to enable "developer mode" on the device, which is an arcane dance that involves navigation through an obscure tree of settings and then quickly tapping a mystery spot 5+ times. Google can't block adb, because that is how Android apps are developed and tested, just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

This is so far from a realistic and acceptable substitute that I question the honesty of anyone who claims that "adb will still work, so no problem!"

I hope that explains my seemingly critical omission.

▲

eminence32 9 days ago | parent | next [-]

> just how Apple cannot block their developer tools from being able to transfer apps onto an iPhone.

If I recall correctly (I might be wrong, because this was 10+ years ago), but Apple did exactly this when the iPhone was first released. When the iPhone first came out, Apple released its XCode devtools for free, including an iOS emulator that you could use to test your iPhone app. But you had to pay a $99 USD per year "developer program" free in order to use the devtools to test the app on your physical device.

If Google is also blocking preventing you from loading your own software onto your own phone with adb unless you pay a free, then this would be a very important thing to call out explicitly.

▲

marcprux 9 days ago | parent [-]

You recall correctly, but that did end in 2015, when Apple ended the requirement that developers sign up for their paid developer program to be able to develop and test iPhone apps. I've written about that elsewhere: https://appfair.org/blog/gpl-and-the-app-stores#fn:3

The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone: technically possible without paying a fee, but enough friction that no one would seriously consider as an alternative solution for publishing their apps to a general audience.

	▲	iggldiggl 8 days ago \| parent \| next [-]
		> The adb workaround for Android is essentially on par with being able to use Xcode's tooling to install apps on an iPhone The Apple situation is still significantly worse than ADB, because (at least without a paid-for developer account) AFAIK you're limited to a certain number of in-development app that you can install simultaneously and you definitely need to reinstall them every few days. ADB currently has no such restrictions.
	▲	kmeisthax 9 days ago \| parent \| prev [-]
		Apple has actually increased the friction since: you now have to enable a scare-screened developer mode, reboot your device, install the app, get an error that the app is untrusted, then go to the part of Settings used for corporate management profiles to enable your own developer profile, and only THEN will the app actually launch and run.

▲

qiqitori 9 days ago | parent | prev [-]

I think your position is valid.

Note: Apple restricts apps uploaded with Xcode, (depending on how it is signed I believe) to 7 days or 1 year. adb currently doesn't have this limit.

But what if they find that somebody made 'sideloading' 'too easy' again. E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop. Then their currently proposed new rule would become ineffective and due to whatever thought process they arrived at their current conclusion, could place similar limits on adb.

	▲	iggldiggl 8 days ago \| parent [-]
		> E.g. somebody could come up with the idea of running adb or an adb emulator on another phone, or even a small hardware dongle, integrating it with a pretty UI that looks like a regular app shop. That idea already exists and is called Shizuku. You don't even need another phone, because ADB also has a mode for wireless debugging via the network, so you can just use that to locally connect to the ADB daemon running on your own phone.