Comment by BatteryMountain
15 days ago
I've built a couple of tools for myself over the years, some of which includes android apps. They were never released to the public.
If we go down this path, I will stop all development on android (and at work too, as it is up to me how we deliver, coincidentally). I implore all other developers to resist this. This will completely lock down the platform forever, there will be no going back.The entire reason why android is so attractive is because we have linux in our palms and all the amazing benefits of that. If google wanted to do the right thing, they would go in the opposite direction and make it easier to gain root access on mainstream devices instead of locking it down further.
It seems the only last bastion left is Firefox, so I will be focusing on making all my tools work well on Firefox (mobile & desktop) instead of app ecosystems.
Developing for Android and iOS is already a huge pain, browser based experiences can be even better than native apps in some cases. I will also not invest any more time in developing/following these closed platforms, and try to push web based solutions as much as reasonably possible.
Seriously, HUGE pain in the psu. Javascript is a pain on web but mobile development significantly more painful, even though we have nicer languages & compilers - all the ceremony around it is just too much.
I freaking hate gradle with a passion, as every other week I have to reconfigure my ide, again. As it cannot seem to just chill out and do its work, it demands blood every week or two.
> I freaking hate gradle with a passion, as every other week I have to reconfigure my ide, again.
Is there a Googler here that can enlighten me what makes Android so unique as to break IDE between every release?
1 reply →
I recently explored wrapping my somewhat-popular website as an app, only to discover that Google wants apps to offer some unique functionalities that the website doesn't support, otherwise they'll reject it as spam listing.
The examples they list of such features are offline support (PWA already allows that), push notifications (browsers already support that), integration with hardware (not applicable), mobile-optimised UI (really?)... all nonsense.
I know they're not strict about this policy as I can name many local apps that are just wrappers of the web version, but I abandoned by idea immediately as it's not beneficial to me in any way to prioritise one particular platform over the others.
> browser based experiences can be even better than native apps in some cases
Not in some cases, in most cases. Clicking shared Google maps link easily opens correct spot on Web, but redirects me to the App Store for God knows reason why on iOS. If I ever need to interact with a new resource, I go check if there's a web site first. If there's no website but there's an app and I don't really need the resource I just drop it altogether without checking the app.
The only apps, besides built-in ones, that I use are chat, bank clients and some home app automation tools that would be problematic to operate as a web app.
Quite honestly, developing for Android and iOS is no longer worth it. I was planning a set of cross-platform native products using Flutter and other tools, but after a careful analysis came to the conclusion that it makes no sense. You have to distribute 5 different apps (Linux, macOS, Windows, iOS, Android) with 5 different packaging, signing, and distribution requirements and have to fight with all kinds of garbage, from Gatekeeper over expensive certificates for Windows to avoid being flagged by antivirus, to anti-competitive app store requirements by Apple and Google.
Web apps have become unavoidable. Native is beating a dead horse.
Let me unpack something: I've been building a commercial product with flutter for the past 2 years. I think after this project is "done" I will never touch cross-platform frameworks ever again - only native. Cross-platform frameworks (like xamarin, flutter, react=-native) - its all lies all the way down. The benefit of having the "one" codebase is so tiny you might as well skip it. The moment you build something more complex than a todo app, when you need reliable background services etc.. guess what, the only reliable way is to revert to kotlin/swift and call it from the framework anyway, as the community packages are truly half-baked messes, abandoned messes, anonymous messes (who is the maintainer?). So never again. Huge waste of time and effort. Then during the release build, you need multiple signing keys, multiple build servers, often multiple pipelines, so what exactly is the point?
This has not been my experience with Flutter at all. It's made building a non trivial cross platform app so much easier and for the few things I've needed to drop down to native it's been very easy.
Was Qt not possible?
1 reply →
I've stopped developing for android as I did not want my address to be public for everyone thanks to google's decisions on how to interpret the EU regulation laws. I'm definitely not surprised by their current behaviour
Firefox is only a browser, you could target libre Linux/BSD/etc platforms instead?
> Firefox is only a browser
Modern web is a platform.
Not for native software though
2 replies →
Would you be willing to outline this in more details. I feel like I am in the same boat but arrived at a different point. Are you building your tools as pwas that you run in Firefox? I've landed at porting my things to pure Emacs lisp but this limits me on ux to well an Emacs frame.
Firefox - you mean Mozilla with its dozens of scandals, money squandering, that is entirely dependent on Google financing (and now endorses its AI tool within the browser). There are some good Chromium and Firefox forks. There is nothing else much left.
https://arstechnica.com/tech-policy/2025/02/firefox-deletes-...
I wounder how long would they last if they would have to do browser engine development themselves.
Until Ladybird is ready (which may take years) for all the Mozilla’s scandals there is not a lot better around.
Fair enough.
I meant more in a technical sense & openness.
They could flip the switch on that in a second after a phone call from Google (or more likely a personal visit with no potential recording devices around.) We could call it Manifest V4, "the compromise."
We really stuck it to those bastards at Google, and they conceded that we could continue allowing the interfaces that efficiently enable adblocking, and still be conformant with the new Manifest V4. We'd just have to put every new add-on through a simple process to make sure that they weren't abusing that privilege.
I mean, they long ago disabled unsigned add-ons in everything but developer nightly iirc? It can't even be considered an entire step to say that only add-ons signed by Mozilla will run; more like a slight lean.