Google is not only killing their own projects, but other people's, too.

I'm no fan of Google, but it's slightly more complicated than that, there's a lot of security and privacy stuff that can't be enforced if your app was build 6 years ago and still slopping around.

Does that really matter for a local-only 5KB app that only talks with my phone‘s flashlight, or reads sensor data? Now, maybe for the 500MB adware-filled “flashlight” app that connects to 100s of servers and demands access to everything my device can do, but that would be banned on any competent app store anyway.

No but enforcing policy is manageable. Enforcing reasonable security measures based on nuances and case by case situations is not manageable for an ecosystem of that scale.

I don't know if this is still the case, but at one point the permission needed to access the flashlight also gave access to the camera. And there aren't restrictions on network connections from apps. (I'd love to have app network access restricted by permissions, but that would be a large change.)

And in any case, Android has had built-in flashlight support for a while now, for any phone that has a camera with a flash. Is the "turn the screen bright white" style still useful with modern Android?

Kind of a side note, but flashdim is an amazing open-source flashlight app that everybody needs[1][2][3].

[1]: https://github.com/cyb3rko/flashdim

[2]: https://f-droid.org/en/packages/com.cyb3rko.flashdim/

[3]: https://play.google.com/store/apps/details?id=com.cyb3rko.fl...

It is if your flashlight's broke.

GrapheneOS (https://grapheneos.org/) contains network access permission.

This is something that really bothered me - I had an app that was small and worked fine on the latest Android OS, yet they took the app and account down because we hadn’t uploaded a new version in a year. Appeals didn’t help

What was their reasoning?

To keep you running on the hamster wheel.

They'd ban Mozart and Shakespeare from the app store if they could.

I don’t think that was their reasoning.

Like, Google, all these megacorps, they are bad, but we should at least argue against their actual arguments.

Their reasoning is probably security. They're working under the assumption your app takes untrusted input in some way, maybe over the network. Which isn't a bad assumption, I mean almost all apps do. Very few apps are true self-contained applications, like a calculator.

So then if there happens to be some vulnerabilities in an older Android SDK then your app is susceptible. They could patch back security but that's expensive after a while. Easier to force app makers to update their apps.

3P app developers are also complicit. Often they deliberately cut off support for old OS's and old devices, because it's "too hard" to support them or whatever. Everyone seems to be working together to keep us on the hamster wheel.

Granted, it is hard. It's a whole extra version to QA on. If it works fine, fine, but if there are consistent negative user reviews on a version with < 5% market share, it's not worth it.

We don't support old iOS versions at all. We can't source new devices on old iOS versions so we can't reliably develop or test on them.

Exactly how I feel about every new React framework. It’s strictly worse than using any other framework and every recruiter continues to ask for it.

Don’t want to speak too negative in regards to the orgs which use it but definitely wouldn’t be the best choice from an engineering perspective for a new project.

Sorry I am not a front end developer. I am a general software engineer please don’t effectively sabotage my career because Silicon Valley wants to make the entire discipline a group of hamsters learning tools which aren’t used by the largest organizations.

> "It’s strictly worse than using any other framework"

If you actually believe that, consider yourself very lucky.

React, like any FE framework, can be implemented well or implemented badly.

React benefits from a very strong (imo the strongest) ecosystem, so if you set up your tooling and patterns correctly its fantastic.

Here's my personal preference: NextJS as the backbone, RTKQ as the central data retrieval/API calls/caching management, RHF for form handling, ag-grid for data grids, and MUI as the component library (can optionally switch this to any equivalent).

If components are designed sufficiently generic and customizable, RTKQ is used to keep data fetching on component instances, and central state storage is avoided as much as possible, it's a great system. Unless you just really hate JSX syntax or something.

There may not have been any. Individual app-store reviewers can block you any time they feel like it, the guy checking your appeal is the same, and none of them have any real pressure to behave unless you have money and corporate power behind you.

That's horrendous, but it fits with Google's method of releasing a product, immediately abandoning it, and shutting it down permanently a year later.