The fastest, least ad-filled and micropayment filled apps are usually the small ones. By downloading a 3 megabyte thermometer app you'll be much happier than a 150 megabyte thermometer app.
They'd ban Mozart and Shakespeare from the app store if they could.
Like, Google, all these megacorps, they are bad, but we should at least argue against their actual arguments.
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.
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.
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.
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.
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?
[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...
There's also currency / unit converter and calendar by Sam Ruston which are in the same vein very good and clean.
These applications are blessedly feature complete, and I haven't noticed any issues being "stuck" on the F-Droid versions.
[1] https://github.com/SimpleMobileTools/Simple-File-Manager
[2] https://f-droid.org/en/packages/com.simplemobiletools.filema...
Forgot about that!
The gallery app is superb.
* build a nice product
* become popular and gain trust with customers
* sell the company to a scammer
* profit!
> My customers can follow me to my next project.
If you are willing to sell your customers to an ad firm, why should they trust your next project?
Often times the hiring managers wanted to see something more akin to a portfolio, like an art project, for apps that many times didn’t exist anymore or have a production server up anymore
But the more arbitrary metric was trying to be sure that I worked on anything “big”
And the 8-12 megabyte package sizes - which I spent a lot of time optimizing with many competence inspiring techniques - would signal that the app or service or userbase wasn't big. Which had nothing to do with anything, could have hundreds of millions of downloads and users
In that space there is a huuuge incentive for bloatware
although a form of affirmation about my experience, and caked in privilege, my experience is that a company that does one odd thing during an interview process isn't indicative of anything. actual job and team I’m on can be fine
(Only partly a joke, etc.)
Let me filter by apps that cost money, are ad free, and sometimes even: don’t have in-app purchases.
Does such a thing really exist? Or are you just making a point?
Even something as silly as an app that does nothing can run into these issues. The APIs and other interfaces used to run applications are imperfect. Sometimes doing nothing about it is a choice, sometimes the vendor doesn't deem that acceptable and then it is no longer a choice. Either way, the application will have to adapt or degrade (to the point where it degrades out of existence).
Changing from using one system API to another shouldn't push an app over an N MB filter anyways. If the user runs into an issue, they can update. Otherwise, if it still works fine just continue to use it.
The argument for updating to keep up with API changes can also be flipped against updating to protect against UI/UX changes. I have lost features from Android updates that I have never been able to get back on my phone, only recreate them on my GNU/Linux desktop.
1. The app was not very optimised, perhaps created by a novice, containing a lot of things it doesn't need.
2. The app used to be really small, but a lot of extra code was added to serve you ads, profile you for better targeting or do sneaky stuff you didn't ask for.
i wrote a calculator app including its own implementation of decimal floating point and it's still only 20 kilobytes
2. The Qalculate CLI is 2mb, so perhaps your 20kb calculator could add some features while still being a 100% pure calculator
If you're using Rust and you have to compile in the whole world, probably not gonna be that small.
And this is why a good '/S' keeps you safe from misunderstanding.