Live data from Hacker News

Prisoners of Google Android development

solutional.ee

111–120 of 318 posts

Re: Prisoners of Google Android development

#111
There's plenty of reasons to complain about the things Google does, but this isn't one. This failure is purely on the author.

1. Google had been mentioning this change for a while 2. Target SDK update is a big deal, especially if you don't know what legacy stuff the app was built on, and surprise, can impact OS versions differently. 3. The emulator is not a good gauge of reality. I get this for a constrained team, but if it didn't cross your mind to even think of if Samsung or some other manufacturer has issues, you're showing you've done little Android Dev. 4. Straight 100% rollout. WTF. The other three, I can see some very isolated reasons for not knowing, but you manually have to change the rollout from 20% to 100% when you release. You said nah, I'm 100% sure of this code I don't know and pushed it. 5. The issue was realized after the customer reported the issue, and was almost ignored. Author released the app and didn't bother to look at crash reporting in the console which would have a strong indicator if any fresh crashes. If you gave half a care, you'd have been all over this the day of a release.

I get it if you're a fresh web dev or something experimenting with Android, there will be surprises. And we can complain about Android backward compatibility and play store practices all day (I often do), but this isn't that. This was the mental equivalent of wanting to find out what lives in a hole in the forest by putting your hand in it first. Little to no thought of consequences or what a professional would do.

I don't care if you don't like mobile, you're telling someone you know mobile enough to maintain their apps. You don't. This is negligence to a degree I'd be worried about getting fired, if not also sued over.

Re: Prisoners of Google Android development

#112
post #60

These minimum SDK requirements have been known for a very long time. It's correct that the email only got sent recently, but the requirements are usually announced 2 years in advance in this manner: After 0 days: New Android version comes out After 1 year: App Updates need to target the latest Android version After 2 years: Apps can't be downloaded on devices with the "new" Android version anymore unless they target…

Many companies, institutions, public bodies hire external contractors to do a one-time development of a limited-scope app. I bet a bunch of them have their Google Play Console dev account email read by people in some engineering infrastructure function who know nothing about Android development.

Updating their apps now means an internal scramble and unexpected project costs. Not saying its wrong or that we shouldn't move forward. Just saying many were complacent and contractors may have good opportunties in this space.

Re: Prisoners of Google Android development

#113
post #25

This is a no-win situation. MS expends an inordinate amount of effort on back compatibility, and much kudos to them. But it vastly increases their attack surface. Likewise many of the worst things about the unfairly maligned C++ come from a hardcore position on back compatibility: as much as possible, old code, and even old C code, should continue to compile and work as expected, even to the point of linking old bina…

The middle ground that I think helps everyone is, change your api and break compilation. Let devs fix the compile errors and use the api correctly, etc. But don't change the behavior of existing functions with the same signatures. As an api provider, do your best to make compilation mean something.

Re: Prisoners of Google Android development

#114

Earlier quoted context omitted.

I disagree, at least on the Android side of things (Apple has long been hostile to PWAs). Installing a PWA from a website is trivially easy on Android, it's just that most users really have separated in their minds (not surprising due to history) that apps come from app stores, and the browser is used for websites. Also, Google has made in much easier in recent years to submit plain PWAs to the Play Store: https://yo…

> it's just that most users really have separated in their minds (not surprising due to history) that apps come from app stores, and the browser is used for websites. Right, because for a very long time (and maybe still) PWAs have been much closer to terrible websites than good apps. They generally don't have the same UX properties as real apps. Remember when the iPhone first came out and web apps were the only optio…

But nowadays you can't really see the difference between good webapps and native apps. We also migrated our native apps to full SPA apps. And really it makes development so much easier. The apps we have are relatively simple without fancy stuff. But the css render engine is fast. Even on Android. And we reduced some of our apps from 30mbs of java code to 150kb of java/typescript. Plus as a bonus we can have a website and serve ios as well. For us there is really no reason to go back. Sidenote: some parts of the app are still native. Ads, Auth and analytics

Re: Prisoners of Google Android development

#115
post #59

IMHO, there are too many drawbacks to being forced to distribute an app through only one "self-authorised" app store and very few advantages. Pros (ironically): 1. the app store manager is supposed to check the app for malware and viruses before publishing it, ironically all the apps full of Google ads, Google and Facebook trackers of any kind are welcome ... 2. make it very easy for the user to search, install and u…

You forgot another pro: it keeps the Boston Strangler[0] out of your house. By tying users' hands behind your back you can ensure that you dictate the terms by which they use your work. No piracy, no adblock, etc.

This is why game developers largely fell in line with the "Licensed by Nintendo" model back in the 80s and 90s, and mobile app developers did the same thing with the iOS App Store in the late 2000s. They don't want to work directly with users to circumvent the platform owner, they want the platform owner to tie the users' hands, and they're willing to have their hands tied in the process.

In the specific case of, say, your banking app; they want secure remote attestation so they can ban users that are running credential stuffing attacks against their app, prevent malware from opening your banking app and clicking the "pay fraudster" button, prevent users from extracting various tap-and-pay related encryption secrets, and also prevent them from injecting stolen secrets into their phone app. The app cannot, on its own, validate that the user's hands are tied; it needs a trustworthy (to them, not you) third party that lives in the boot chain and/or EL3 to validate that. So they don't want to just give you an app and a signature. They want Google to do it so that Google can tie your hands.

It's important to note that all the user-facing benefits of app stores are backreasoning. The goal from the beginning was to tie users down, because to them, users are little thieving mosquitoes. This is the "quiet part" that they don't say out loud.

Let's hope to dear god that Google's WEI proposal doesn't happen and PWAs never have access to attestation. Google already has the whole "we don't let you login on unknown browsers" nonsense and we don't need that cancer spreading.

F-Droid is great. Google's shenanigans with Android need to be shut down. Hell, the EU was able to do that but the US needs to also do that and have it apply internationally.

[0] MPAA code word for noncommercial small-scale copying, i.e. someone with a VCR taping shows off TV. Jack Valenti really was a piece of shit, wasn't he?

Re: Prisoners of Google Android development

#116
post #26

> I'm not even sure why are we, as developers, allowing this to happen — there's usually not any good reason to develop mobile applications at all anymore. It's time to move back to open (web) standards and take control back into our own hands! In general yes, but if I look at the apps on my phone I have A mail client, K9, old UI. This clearly can't be replaced by a web app because I'm using it to look at my mail in…

Those could all run in a browser. A PWA isn't cloud software, it's just software that runs on your browser. But they would indeed ask for all kinds of permissions. And K9 and the network scanner would get a really scary-looking permission dialog.

Mozilla would cry bloody murder if Google proposed a raw sockets API for the web, for the same reason why they oppose WebUSB & friends.

Re: Prisoners of Google Android development

#117
post #51

I also got this email, but professionally and personally. Personally, I voluntarily built and run open source apps for 16 different cities for their transit system. This gave me two weeks to update 16 apps, for no benefit of anyone. My app is a PWA, and the Android version just uses cordova + a few plugins to add a few native options. Unfortunately, updating cordova to support the new target android api broke some of…

> Truthfully, I'd prefer to get rid of the app and just have users go to the website and install the PWA, but the average user still doesn't know how to do this. And the Play Store is still the first place users go to find apps. If google would just allow submitting a PWA directly to the app store, that'd be nice... I am not looking forward to doing this yearly.

This is what Trusted Web Activities (TWA) are for, you can use it to list PWAs in the Play Store without frameworks like Cordova

https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...

https://developers.google.com/codelabs/pwa-in-play#0

Re: Prisoners of Google Android development

#118

This is a problem with software culture in general. 99% of us refuse to declare an application "done". We're always working on the next iteration, over and over forever. Cramming unwanted features, changing the UI over and over, updating dependency 2.8.1 to 2.8.2 and re-building. Most of it is change for the sake of change. The app stores obviously believe in this endless treadmill, too, and enforce it: Since everyon…

> 99% of us refuse to declare an application "done". The article is literally about how they are not allowed to declare the app "done" because google is forcing them to upgrade to a new version. I'm sure the creators of this app wish they could just never touch it again.

That's the point. When you're that one person who wants to, you're swimming against the current.

Re: Prisoners of Google Android development

#119
post #19

Why not using an alternative to Google play store, at least as a fallback in case of emergency...

Honestly this is really not a solution for anyone making a living off apps, or working on apps in a professional setting. You simply reach much fewer people and certainly a different audience too.

Re: Prisoners of Google Android development

#120

I've started frequently getting reviewed (from submission to approval) within hours, sometimes even within 10-15 minutes of submitting to Apple App Store. But it still varies and can take a day. I want to figure out a good cross plat strategy but would not want to ever deal with Play and Google.

Our average in the Play Store is about an hour. Our average on the Apple side is a bit longer, but we've been blocked by them on multiple occasions for over a week while we turned out to be in the right.
Post reply on HN