upvote
If this finally pushes adoption of truly open Linux phones, then this will end up being a good thing, and the greatest favor that Google could do for the open source community.

Tragically, Linux phones have languished and are in an absolute state these days, but a lot of the building blocks are in place if user adoption occurs en masse. (Shout out to the lunatics who have kept this dream alive during these dark years.)

reply
It won't though, because there's a ecosystem of banking/insurance/whatever apps that have bought into the android/iphone lockdown mindsete that people will simply be locked out of. Open alternatives can grow when there is a viable means of slow growth, and cutting off the oxygen to such things is the implicit intent.
reply
> banking/insurance/whatever apps

I know banking apps are the typical example, but I've always wondered why. I use my bank's app maybe once or twice a year when I need to Zelle someone, which I only need to do when they don't have Venmo. (Unless we consider Venmo a banking app.)

I only have one bank's app installed, the rest of my banks I only interact with over their website, on desktop.

As for insurance, I've never had an insurance company's app installed.

Am I just an outlier here? Honestly, if I switched to a non standard OS, I'd be more annoyed about losing, say, Google Maps, Uber/Lyft, or various chat apps. Banking and insurance just don't come to mind at all as something I need my phone for.

reply
My bank sends me an alert when my card is used to make a transaction - handy for spotting fraud.

I get an alert when a payment comes it - handy for knowing if a client has paid.

I can quickly check my balance - handy for knowing if I can afford another round of drinks.

I can repay a friend in two taps - handy if they've paid for dinner.

Is anything essential? No. Is it something people use multiple times per day? Yes!

reply
Could all of these be handled through openbanking?
reply
I can get alerts in email or messages, no need dedicated app for that, I can track there also my balance, so only useful thing app provides are easy wire transfers from phone, which I never do, if I wanna transfer money is much more convenient work big display, proper keyboard and mouse than from phone.
reply
That's great for you but unfortunately the overwhelming majority of people do indeed regularly use these features.
reply
"I'm am just an outlier here?"

No. The "banking app doesn't work" argument against non-corporate mobile OS, raised incessantly is HN comments, is bogus

I want a "phone", i.e., small form factor computer, that can run something like NetBSD, or Linux. But I have no intention of using it for commercial transactions. Mobile banking is not why I want to run a non-corporate OS

I want to use it for recreation, research and experimentation

reply
> I want a "phone", i.e., small form factor computer, that can run something like NetBSD, or Linux. But I have no intention of using it for commercial transactions. Mobile banking is not why I want to run a non-corporate OS

> I want to use it for recreation, research and experimentation

I am a firm believer that phones are personal computers and should have all the end user freedom we have come to expect from personal computers. I am totally behind what your saying.

Personally, I opt out of services that require the use of phone "apps" and any potential attestation they provide. Unfortunately, I just offload that into my wife's iPhone. Want to go to a concert in a TicketMaster venue-- you have to have a phone. Pay to park in some places requires a phone. Mobile ordering for some restaurants requires a phone.

I don't think it should be this way, but it is. I think we need consumer regulation to insure software freedom on phones and curtail awful user hostile "features" like remote attestation.

Until that happens (if it ever does) there is a realpolitik with needing corporate phones for some activities that can't be denied.

reply
2FA is a requirement in Europe. I can't log into my bank account without my phone being able to run the app.
reply
But 2FA is moot if it’s the same device as your bank app, is it not?
reply
I would stop using bank requiring phone app to do banking, simple as that, both my main EU accounts use sms verification codes and extra password, which is fine with me. If they will require an app, they will lose customer.
reply
2FA and Google SafetyNet are two completely different things. Your banking app can implement 2FA without SafetyNet.
reply
Banks often use their app for a second factor auth. here.
reply
I can't deposit checks over the website, and I use a bank with no physical locations near me.
reply
That's true, but the notion that we're still using paper checks in 2026 is so crazy. And yet they remain the cheapest way to handle many transactions in the US financial system. Like a lot of small healthcare providers still prefer to receive paper checks from insurance companies because the electronic payment processors take a 3% fee.
reply
I haven't had issues with the mobile apps of 3 of the most major US brokerages. They run fine on rooted phone. They do everything I'd want a bank to do anyway.

Ditch your bank if they have issues. If their retention department asks why you're leaving, tell them their app doesn't work.

reply
The best solution for this is to buy a $30 burner phone at Walmart and use it unactivated, tethered to your main de-Googled device. You can use the burner for only tasks requiring Play Integrity.

Make sure to leave one star reviews on all such apps that you run into.

reply
Have a look at this post

https://news.ycombinator.com/item?id=46723594 from Emre @emrekosmaz

It is a smartphone that runs Android, launches Debian, and dual-boots Windows 11

Actual link https://nexphone.com/blog/the-tale-of-nexphone-one-phone-eve...

reply
Until Android is crippled it will continue to take resources away from Linux Phone development and companies that will launch phones for it
reply
For me as a desktop linux poweruser, I find this potential transition pretty intimidating, I've never flashed a phone with a custom rom let alone switch to a completely different OS, and I am not sure if the phone can even be reset to its original OS, if things go south.
reply
It's relatively easy. It's basically a command for each step you want to do and it tends to fail gracefully nowadays.

If you can install a linux distro you can flash a custom rom on a well-supported phone.

If it were more mainstream I could see GUI apps to manage all this for people, if they don't already exist. Idk I just use adb.

reply
It's also high risk. I've bricked two phones doing it.
reply
I flash phones almost every other week. And tablets. I have been flashing since Androids came out. But never bricked. But maybe that is why I don't have any problems.
reply
it's pretty much impossible to hard brick phone, you can almost always recover it

I'm running custom ROMs for the last 15 years

reply
I've been flashing phones for over 2 decades and have never bricked a phone. How did you manage that?
reply
Same here. Just follow the LineageOS steps.
reply
Are you seriously implying that flashing phones doesn’t risk bricking them or you’re not aware of that risk are you serious?
reply
I am seriously unaware of the risks and also flashing brand new phones :)
reply
> Are you seriously implying that flashing phones doesn’t risk bricking them or you’re not aware of that risk are you serious?

Yes, that is generally the case. As a general rule with an Android phone reflashing the OS itself or the bootloader carries no risk of bricking the device (meaning making it impossible to recover without specialized hardware and/or opening up parts that were not intended to be opened).

There are plenty of ways to "soft-brick" a device such that you might need to plug it in to a computer, and adb/fastboot can definitely be a pain in the ass to use (especially on Windows), but if you have a device with an unlocked bootloader it's very rare to be able to actually brick the device while doing normal things.

Now, if you're doing abnormal things like reflashing the radio firmware you can absolutely brick some devices there, but you don't have to do that just to boot an alternative OS and generally shouldn't be doing it without very good reason and specific knowledge of exactly what you're doing.

I'm not going to say there are no devices where the standard process to flash an alternative OS is dangerous, but none of the relatively common ones I've ever owned or used have been built that way because OEMs don't want their own official firmware updates to be dangerous either.

tl;dr: It is sometimes possible to brick a device by flashing the wrong thing incorrectly, but the risk of doing that if you are just installing an alternative OS through a standard process is basically zero.

reply
Potential for a brick varies massively depending on phone model, doesn't it?
reply
That describes relatively easy for you, but not for the average person who can’t even be bothered to change the default ringtone.
reply
The challenge I've found when looking for instructions for flashing one of my old phones is the assumption of knowledge some rom builders have, or perhaps an assumption about their audience. This seems like it has the potential to bit someone in the ass because if they're relying on other sources like the lineageOS wiki or forum posts elsewhere for example there's no guarantee it'll stay available, complete, or relevant to their variant over time. It's an added burden for what is a gracious volunteer role, but it's a handicap if they want more people using the fruits of their labor.
reply
Even if you have linux, there are still third parties that have control over your hardware. Even if you're using graphenos, you can't block the sim or the cellular radio stack, and likely other modules on the SoC, from at-will access to every sensor on the device. You can at least protect your files, unless there's a mitm or other vector that graphenos can't cope with. And at worst, they can simply clone all your encrypted bits and wait on Moore's law or sufficient cubits to go back and crack the copy, on the off chance there's anything they want with your data in the first place.
reply
My phone has hardware kill switches for modem, WiFi/Bluetooth and mic/camera. All three together also kill all sensors.
reply
If it's got a sim card, it's still phoning home and providing location data. You can't escape the panopticon. A faraday bag gets you mostly there, though, but the point isn't that you can maneuver against it, it's that the device and its operation is fundamentally compromised by design.

There's a whole lot of shady crap underlying the infrastructure and the hardware that consumers cannot touch, pinephone / librephone or otherwise. It's not designed for consent. At best you can gain ephemeral relief, but even that is illusory, because by simple process of elimination, differential analysis allows fine grained ID and tracking of people even if they don't have accounts, phones, interact with websites, etc.

It's not a shady cabal of lizard people, it's just the grubby natural alignment of interests by a wide ranging set of companies and regulators and groups who allow it to happen without imposing any accountability, and ensuring that the system remains structured such that no effective accountability can be imposed.

Extorting constant streams of data for adtech is too valuable and the entire thing is too complex for silly things like ethics to interfere.

reply
> If it's got a sim card, it's still phoning home and providing location data

Only when the kill switch is on. I control it.

Also, it's possible to get AweSIM service hiding your data from the mobile operators.

reply
For sure - and you can use WiFi only, set yourself up with a HaLow rig and give yourself a ~10mbps connection anywhere up to 10 miles from your home, suitable for voip and low rate streaming, throw in VPN, and remain completely off-net as far as cellular networks go. I'm actually planning on using a wireless touchscreen and mobile halow/raspberry pi network/storage stack to completely replace my phone, but the bigger issue is automated tracking of everything - if you're the only blank spot in a sea of known individuals, it's just a matter of seconds to id you, since everything everywhere about everyone is tracked online.

We should be enforcing informed consent regulation of network infrastructure, treating privacy and anonymity as synonymous with liberty and freedom. Allowing the system to operate as it does is a choice; those with lots of money get to make it grow by exploiting a constant invasion of privacy with no concurrent return to the society being exploited.

Phones aren't built to be privacy respecting, and kill switches are a mitigation of a symptom, they don't do anything to address the disease.

reply
Expecting Google to give up control of one of the only alternative operating systems is right up there with believing in the tooth fairy.

What you're saying should happen, but it will only happen when the government legislates it happens; which frankly they should be doing (along with nationalizing a few other software projects to be fair).

A trillion dollar transnational corporation with massive monopolistic tendencies will never ever do the right thing. Expect to force feed it down their throats.

reply
In general, governments seem to be much more invested in making it illegal to have anything that is too open and too free. Even EU is lusting for draconian control features like chat control where you don't own and operate the software you installed on your device even if, at the same timem, they're trying to gnaw on the influence of Big Tech.
reply
The limitation of linux phones is hardware. I have been watching the progress of postmarketOS on the fairphone 4, and looks promising.
reply
reply
I don't care about specs, I care about functionality and price. The camera on the pinephone doesn't practically work because it is too slow and the quality sucks. You basicially cannot record videos whatsoever. I can't use the device for GPS navigation. I can run whatsapp within waydroid, but it isn't practical due to the battery life and startup limitations that imposes. The GPU on the pinephone sucks, is underpowered, doesn't support OpenGL ES 3 or vulkan, and the user interface is always slow as hell to navigate.

So practically I cannot use it as a daily driver.

Librem 5 does have enough GPU horsepower, a functioning camera, and good pmOS support. But $800 is a lot to ask to test out switching to linux with no guarantee that my workflow will work or I will have enough battery life. It looks like the librem 5 can't record videos or do GPS navigation yet.

I am looking at the librem 5 specs again. The EG25-G is probably a better starting point for the modem now that it has been better documented and reverse engineered as a result of the pinephone project. It is interesting that the L5 has a generic smartcard reader though.

reply
> If this finally pushes adoption of truly open Linux phones...

It won't.

reply
Good news: You (as a community) can now finally wake up from your dreams and get some things right!

It's really a shame that you always wait until you really get forced. Particularly in situations when every individual's inability has consequences for the others as well. I really gave up all ideas of a better world. With this community, the best you can hope is that the decay will be slow.

So everyone who would describe himself/herself as a FOSS enthusiast, or at least a friend of a somewhat open system where the user has some actual rights beyond sole consumption, put some pressure towards having actually de-Googled systems. A system that mostly comes from Google, would not fit my definition of that term at all! Even if they removed some parts of it. It's an euphemism. And it's dangerous because you constantly get trapped by these euphemisms. Ever. Single. F'ing. Time.

reply
Good thing restricting side-loading isn't legal in the European Union! Not a problem here. Apple had to enable side-loading on their EU-based phones and so will Google if they restrict it.
reply
Yes it is, and no they didn't. Apple has to allow (heavily restricted) alternative app stores, and I'm not clear on whether any actually exist right now.
reply
My understanding is that how Apple is restricting the alternative app stores is also illegal in EU, so I don't thinkt this is the end of this story.
reply
It's almost two years and they are still doing it. So they are moving mighty slow if that is the case.
reply
Yes, these things move slowly, but they do move =)
reply
How specific is the law? What if side loading requires a "trusted" signed certificate where trusted means from Google Play?

Not even playing devil's advocate, just wondering how many loopholes actually exist.

reply
If a lawsuit tackles this problem in the EU, will we finally also see somebody go after MS for their obnoxious code signing certificates?

While MS code signing certs are more circumventable for power-users than Android's new approved developer program, their pricing is far more prohibitive for independent OSS developers and hobbyists, costing hundreds of USD per year.

reply
The kind of "side-loading" of notarized apps outside the manufacturer's app store that Apple allows in the EU is exactly what Google proposed to do for all its Android builds. We don't want that.
reply
The only reason I was sticking to Android for years is this. And I think there is no moat for Android. I would rather switch to iOS if both platforms are same restrictive.
reply
The impact is a direct threat to independent AOSP distributions like Murena's e/OS/ (which I'm personally using).

I don't think this is true, right? An AOSP build can just decide to still allow installing arbitrary APKs. Also see this post from the GrapheneOS team:

https://mastodon.social/@GrapheneOS@grapheneos.social/116103...

reply
You can’t really do that long-term as Google will change code that will not match however you are not enforcing this policy

So at the very least you’d have to keep patches up to date.

Long term divergence could be enough that’s it’s just a hard fork and/or Google changes so much that the maintainer can’t keep the patches working at the same pace

I couldn’t read your link as it asks to join mastodon.social

reply
All distributions involve maintaining patch sets. The question is what the marginal burden of this particular patch is.
reply
Doesn't require me to sign in or create account...
reply
The patch set for graphene is substantial, this is a relatively minor change.
reply
Personally I'm excited about the death of Android, now resources can be put toward mainstreaming and maturing the Linux Phone ecosystem

Hopefully 2026 or 2027 will be the year of the Linux Phone

reply
Strong disagree. Linux, its permission system and its (barely existent) application isolation are lightyears away from the security guarantees that Android brings.
reply
Desktop OSes and their derivatives are woefully behind in this regard, and unfortunately the will to bring them up to par is incredibly weak. Of those in mass use (Qubes OS is neat but its user base isn’t even a rounding error), macOS probably does the most, but it’s still lagging behind iOS and what’s been implemented has come with much consternation from the technically inclined peanut gallery.

I understand some amount of reticence with commercial OSes, but there’s no justification for being against it on open Linux based desktops and mobile OSes. We really need to get past the 90s-minded paradigm of everything having access to everything else all the time with the only (scantly) meaningful safeguards coming in the form of *nix user permissions.

reply
> We really need to get past the 90s-minded paradigm of everything having access to everything else all the time

I do agree with that, and I strongly believe that the iOS and Android security model is way ahead of Desktop Linux. But what I observe is that nobody seems to care about the security model. A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".

reply
It comes from a history of using mostly trusted application sources like Debian/Ubuntu package archives with manual review being the norm. And few supply chain attacks.

But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical.

As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more.

Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.

reply
Allowing the owner of the device root access doesn't necessarily break the security model. It just means that the user can grant additional privileges to specific apps the owner has decided to trust. Every other app still has to abide by the restrictions.

The fact that Android complains and tells any app that asks whether the owner actually, you know, owns the device they paid for is an implementation detail.

A Linux distribution that adopts an Android style security model could easily still provide the owner root access while locking down less trusted apps in such a way that the apps can't know or care whether the device is rooted.

reply
Fun fact - on most Linux distros any user program can see almost any event, yes including key presses, by reading from the right /dev/... file.

This is not surprising. The desktop Linux community reacted with hostility to the well funded security efforts (selinux, apparmor, grsecurity, etc)

reply
Do you have any source for that claim? That would be a pretty serious security issue even unrelated to any security hardening (eg. on a multi-user system, one user could read out the password from another user — even with desktop usage, second user could be SSHed in).

As a datapoint, everything in /dev/input/* is owned by root:input on my Debian Bookworm install, and my main user is not a member of the "input" group either.

Biggest problem with most security hardening for Linux desktop is that it breaks the natural usage pattern: I store my files by their content, not by their format (eg. I might have a folder for my project containing image files, spreadsheets, FreeCAD files, maybe even some code or TeX/ODF files). If programs are restricted to access the entirety of my $HOME though, there is not much benefit to that protection since that's where my most valuable data is. If they are restricted to per-program folder, I need to start organizing my data differently and unnaturally.

Android mostly does not use the "files" metaphor and basically does exactly that (per-app data): coming up with a security model and file management UX that does both is where the challenge is.

reply
Security is a tradeoff (fucking always...)

It's the same reason I choose to keep my front door unlocked basically all the time - I know my neighborhood, the risk is really low and the convenience is high.

Further... practically everyone agrees that they don't need bank vaults as front doors. It makes zero practical sense: The cost is incredibly high, and the convenience is very low.

There are ALL sorts of wonderfully cool things you can do on a system where applications are allowed to trust each other, and the system is permissive by default.

You can customize behavior more easily, you can extend software more easily, you can add incredibly detailed & functional accessibility support, you can create incredibly powerful macros and commands.

This is so important that fundamental OS design from the early 90s actually prioritized and catered to exactly this style of open, trusted, platform (ex - all of COM in windows...). This is what made personal computing a reality...

All of those fall flat when you try to impose "well funded" security efforts.

Those efforts have a place, in the same way that bank vaults have a place. Whether that place is a personal computer is a different question.

Implying those folks are hostile for no reason is... at best a woeful misunderstanding of the situation, and at worst a malicious mischaracterization.

reply
Flatpak and Snaps are built to solve this. They do conflict with some expectations from users to be able to play around with things, though, so they do not have the penetration one might want.
reply
They only cover the user-facing app part of the story. The rest of the system needs isolation and safeguards, too, including things like the desktop environment and whatever random daemon.

A solution that's integral to the system and not just loosely taped on is required.

reply
Flatpak provides very weak sandboxing compared to android. It was more about packaging and distribution than security.
reply
Aren't all the necessary pieces for something better essentially in place now that unprivileged namespaces are well-established?

They've for sure had more than their fair share of security issues, but those are bugs, not fundamental design problems as far as I understand?

reply
This might be a strange take in these times, but I feel like the browser largely solved the "I need to run potentially adversarial application code in a sandbox". For native applications, stick to stuff that's vetted and in well-maintained repositories, or well-known open source projects that you trust. All of this technical work just to be able to run hostile native code ignores that you don't have to, and probably shouldn't want to, run sketchy code on your device. Installing random untrusted software is bad, even with the most advanced security model in the world. At the very least it will probably abuse whatever permissions it has to spy on you to any degree it can (which is a lot, even for web pages) and to send you advertising notifications.
reply
This assumes that the mentioned systems are the only security considerations on a Linux system. Clearly this is not the case so I am unsure why you omit other security-related aspects of Linux here.
reply
Android, being based upon the Linux kernel, has all those and its own app permission system built on top. Linux on its own comes nowhere close to this.
reply
You can build those things on top of Linux, like Android did. Linux has containerization and all.
reply
Not lightyears. About 20 years, which is how long it took Google to pile on the mountain of complexity and inefficiency to accomplish this.
reply
I understand why mobile/tablet OSs are so crappy compared to desktop; in the past these devices had no resources cpu and ram wise and had to heavily watch battery consumption (the latter is still true mostly, but that should be up to the user), but my phone is more powerful than my laptop and yet runs crap with no real usable filesystem and all kinds of other weirdness that's no longer needed.

However, I have 2 Linux phones and Linux on phones is just not there. Massive vendors (Samsung, Huawei, etc) would need to get behind it to make it go anywhere. Also so banking etc apps remain available also on those phones. We can already run android apps on Linux, Windows apps, so it would be a bright future but really it needs injections and support for large phone makers.

I hope the EU/US mess will give it somewhat of a push but I doubt it.

reply
FWIW, Nokia did develop a pretty good Linux phone back in the day (Maemo/Meego) with Nokia N9 (it even received rave reviews from consumer tech sites like engadget), but it did get killed off as they got absorbed into Microsoft (we all know that didn't age well).

Similarly, Palm Pre, and especially HP Pre 3 was a wonderful WebOS incarnation.

Ubuntu Touch did seem like it had a future, but it was a massive sink for Canonical so it was defunded as well.

The user experience was there on all of these: the apps, not so much.

reply
Ubuntu Touch is not dead though, I use it happily on my primary device for 8 years. It's working like a charm. And waydroid allows you to run APKs, even if some bank apps may not work.
reply
I.. don't think it will happen. For several reasons too. It is not that I don't think Android will change substantially, but the following constraints suggest a different trajectory:

- AI boom or bust will affect hardware availability - there is a push on its way to revamp phones into 'what comes next' -- see various versions of the same product that listens to you ( earing, ring, necklace ) - small LLMs allow for minimal hardware requirements for some tasks - anti-institutional sentiment seems to be driving some of the adoption

reply
I think adoption will hinge on whether existing Android apps will just run on it with something like waydroid/anbox or not.

Gaming on Linux took off with Proton. Linux on phones might go the same path.

reply
This is one of the most naive things I see people repeat.

The reality is that we're lucky to have mostly-good things at all that align with most of our interests.

Yet people get so comfortable that they start to think mostly-good things are some sort of guarantee or natural order of the world.

Such that if only they could just kill off the thing that's mostly-good, they'll finally get something that's even better (or rather, more aligned with their interests rather than anyone else's).

In reality, mostly-good things that align with most of our interests is mostly a fluke of history, not something that was guaranteed to unfold.

Other common examples: capitalism, the internet, html/css, their favorite part of society (but they have ideas of how it could be a little better), some open-source project they actually use daily, etc.

If only there weren't Android, surely your set of ideals would win and nobody else's.

reply
Agreed that there is a ton of baby in this bathwater.

Also, the open nature of AOSP gave Google its advantage during the early days. Since then, Google has morphed into a company that would likely not make the same decision to create an open-source OS free for others to use and contribute to.

So in the end, what we as consumers actually get, in 2026:

- Google encourages application developers to use hardware attestation to prevent themselves from running on non-blessed, third-party AOSP distributions.

- Google builds basic functionality people care about (including passkeys!) into Play Services, a closed mega-application that happens to require a Google account for most features, and is a moving target for open distributions to mimic.

- Google has closed AOSP contributions to themselves and OEM partners only. AOSP releases are now quarterly source dumps.

- OEMs which traditionally allowed bootloader unlocking (and thus actual ownership of the hardware) have removed it as a matter of policy.

So what exactly is open about Android anymore? Does "source-available OS you can see and not touch" align with your interests? Because it's increasingly not aligned with mine.

reply
> death of Android

death of personal computing freedom, sovereign compute, and probably soon our ability to meaningfully contribute to the field as ICs?

A lot of really bad things are happening to our field, and Google is one of the agents responsible for much of it.

reply
> A lot of really bad things are happening to our field, and Google is one of the agents responsible for much of it.

I mean, breaking news from 2010, but of course never assume things are so bad that they can’t get worse.

reply
>The impact is a direct threat to independent AOSP distributions like Murena's e/OS/ (which I'm personally using). If installing a basic APK eventually requires a Google-verified developer ID, maintaining a truly de-Googled mobile OS becomes nearly impossible.

I have trouble understanding why this is a threat to AOSP distribution. I would have said quite the opposite actually, I don't see why they would not remove the verification and that's an incentive for people to use their project instead of Google Android.

reply
I like it, because more and more people see Google as what it is: a ruthless, selfish and extremely greedy mega-mega-corporation. The less we depend on it the better.
reply
Who could Android be possibly recommended to at this point?

I know iPhones aren't affordable for the layman in many countries. But for anyone with an option, why would you buy an Android? All the "customization" things I cared about when I was on Android are either doable on an iPhone now with better implementation, or something I don't care about.

I was a die-hard until I went through enough cycles of Google deprecating and reinventing their apps and services every year, breaking my workflow/habits, that I got sick of them and moved to Apple everything. And all the changes I've seen since then are only making me happier I got out of the ecosystem when I did. Unlimited Google Photos backups with Pixels are gone, Google Play Music is gone, the free development/distribution environment is gone, etc.

If people can't even develop for the thing without going through the Google process, they're really just a shitty iOS knockoff.

reply
But this thread is about the option to install apps on your device regardless of OS vendor approval, and that's not possible either with iOS nor is iOS open source. And that's what this is all about. If you don't care about open-source and user freedom, then this change wouldn't matter to you anyway.
reply
I switched back to Android in large part for KDE Connect. You can get continuity esque features that work with any desktop operating system. I also get to use real Firefox instead of a Safari wrapper. I still use as few Google services as possible, pretty much just Maps.
reply
KDE Connect works just fine on iOS.
reply
It "works" but it is significantly less useful. Notification mirroring doesn't work, you can't read/respond to text messages, it can't reliably run in the background.

These are all due to limitations imposed by Apple.

reply
At this point, I wouldn't recommend Android other than enjoying the much steeper discount with the headset. For me, the only thing that is keeping me on Android is easier access to commas on the keyboard.
reply
I love the Java/Kotlin userspace, even if it is Android Java flavour, and the our way or the highway attitude to C and C++ code, instead of yet another UNIX clone with some kind of X Windows into the phone.

In the past I was also on Windows Phone, again great .NET based userspace, with some limited C++, moving into the future, not legacy OS design.

I can afford iPhones, but won't buy them for private use, as I am not sponsoring Apple tax when I think about how many people on this world hardly can afford a feature phone in first place.

However I also support their Swift/Objective-C userspace, without being yet another UNIX clone.

If the Linux phones are to be yet another OpenMoko with Gtk+, or Qt, I don't see it moving the needle in mainstream adoption.

reply
> But for anyone with an option, why would you buy an Android?

How the heck this is true?!? iOS is just bad.

Its usability is bad, its interface is bad, its apps are just a ton of crap, and it _will_ keep getting worse.

I'm not even talking about its "walled concentration camp" app model.

reply
you're a really vanilla user then.

wake me up when there's an adblocker on an iphone.

reply
There are several that plug into Safari, and Pihole just works. Does Android have ad blockers that do more? It's been a few years since I switched.
reply
I can run proper uBlock Origin in Firefox on Android. Sure something like Pihole works, but I am often on mobile data or other WiFi networks.
reply
Thankfully you don't really need an adblocker for apps on an iPhone. Your browser could use one, but thankfully those do exist :)

That said, I want off the iOS ecosystem, but Google has basically said guess what? We are going the way of Apple, so we don't care about you either.

So right now there isn't really anywhere else to go. I'm going to keep trucking in iOS for now, but I hope I find something better soon.

reply
> Thankfully you don't really need an adblocker for apps on an iPhone. Your browser could use one, but thankfully those do exist :)

uBlock Origin on Firefox Mobile is significantly better than any Safari adblocker I've been able to find. (1Blocker's the best I've found for Safari.)

reply
> Thankfully you don't really need an adblocker for apps on an iPhone.

That's for me to decide, thank you very much.

reply
who is talking about app adblockers. power android users get their apps from fdroid. You relly are out of touch.

And you know very well, There are only meme adblockers for the browser on IOS.

reply