Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prisoners of Google Android development

solutional.ee

Post reply on HN
Print view View original

301–310 of 318 posts

Re: Prisoners of Google Android development

#301

Post by curt15 »

TexanFeller wrote: post #68
l72 wrote: 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…

> 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 I think you misunderstood users, it's not just ignorance. I want apps to go back in the direction of real(not cordova) apps, not some low effort web thing. Basically zero web apps match the experience of a well crafted actual app.

>I think you misunderstood users, it's not just ignorance. I want apps to go back in the direction of real(not cordova) apps, not some low effort web thing. Basically zero web apps match the experience of a well crafted actual app.

For me, it also depends on how integral internet access is to the application's function. When I'm on my computer and want to check the weather, I don't want to launch a separate application. I just google "weather". I agree that games probably belong as standalone desktop/mobile applications and similarly for other programs requiring deep integration with OS APIs. But if an app mostly wraps content that's already available via a website (e.g. starbucks.com, subway.com, or news sites), I'd rather just use a full-blooded web browser.

Re: Prisoners of Google Android development

#302

Post by jonmb »

kramerger wrote: post #286
dep_b wrote: post #280

Earlier quoted context omitted.

If Google breaks the framework I built, I still blame Google.

Why? Should Android be bloated with compatibility layers for every buggy framework ever existed? Including third part stuff such as Cordova and Ionic that have more or less stopped development? And it's not like Google is randomly breaking things. And even when there are breaking changes they provide support libraries and explain very clearly what has changed and why it needed to be changed. Still, no sympathy for ap…

> Including third part stuff such as Cordova and Ionic that have more or less stopped development?

FYI - Ionic is in active development, along with Capacitor, their replacement of Cordova.

I recently updated my app’s target to the new Google guidelines and Capacitor made it easy with an automated cli.

Re: Prisoners of Google Android development

#303

Post by carstenhag »

izacus wrote: post #152
withinboredom wrote: post #75

Earlier quoted context omitted.

This email was the first I'd ever heard of it.

Play has raised it's tarter API requirements several years now and repeatedly warns a full year ahead of next change. If you never heard of it you've been deliberately playing dumb.

I agree with this being very expected for android devs. But not everyone's role is being an Android Dev. Don't call other people dumb for this.

Re: Prisoners of Google Android development

#304

Post by vimbtw »

hn_throwaway_99 wrote: post #88
BaseballPhysics wrote: post #76

Earlier quoted context omitted.

> 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. Let's be clear: that's not because users don't know how to do it. It's because Google and Apple haven't made it as easy as installing an app from their app store. That's a choice, and it's a deliberate one.

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…

iOS allows for installing a website as an app. You can install PWAs without ever using the App Store.

Re: Prisoners of Google Android development

#305

Post by scarface_74 »

sofixa wrote: post #279
scarface_74 wrote: post #199

Earlier quoted context omitted.

Yes and people still watch TV even though you “haven’t owned one in 10 years”. Or do you think places are making apps that no one uses?

> Or do you think places are making apps that no one uses? Of course, because apps are "modern". You've never seen an app that should have been a website? I know of multiple places that had shitty apps built for extremely narrow use cases that had close to zero use outside of the team that ordered it (while it was meant for a wider audience). And yes, I'm genuinely baffled people will bother downloading an app for a…

Could it possibly be that people on HN are out of touch with how most users use technology?

https://youappi.com/european-app-trends-2022/

Re: Prisoners of Google Android development

#306

Post by janvidar »

cogman10 wrote: post #124
gumby wrote: 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…

I just don't buy this as an excuse for google. The majority of applications deployed to android are targeting android's bytecode. They aren't natively compiled applications. The reason C++ presents insurmountable security problems is it's low level nature and the fact that once you have a native binary, you're done. But a bytecode for a language with memory safety? How would it be possible to not backport security fi…

> This isn't a security issue, this is a "google doesn't want to support the platform" issue.

Well, it is a platform security issue - sometimes a privacy issue.

Google essentially is improving security over time by fixing broken APIs which are deprecated and removed over time.

There are plenty of security and privacy related changes where APIs have been fixed in backwards incompatible ways. Essentially, this has been solved by adding more permissions - where either Google Play, or the user needs to consent.

In order to not break backwards compatibility this has been enforced based on the "target API level", and in order to prevent malware from simply targeting old API levels, they enforce this in Google Play by forcing apps to target current API levels.

In most cases, the changes required are rather small, sometimes code changes, sometimes compliance/documentation changes - or a combination.

Re: Prisoners of Google Android development

#307

Post by amf12 »

izacus wrote: post #156
denton-scratch wrote: post #33

It was always obvious that Play Stores and their captive developer "communities" were a trap. Forced API upgrades are just one aspect of that. There are certainly tasks that are best done by a phone or mobile app; usually, these are things that involve moving around, such as navigation, or depend on phone sensors, such as working out which way is "up". But nearly everything else can be done by a website. I'd hate to…

Funny reading this on a site that regularly tears into Google for not adequately gatekeeping software on Android and advertises iPhones as better because they police more aggressively.

I see cognitive dissonance on this site every day. Android or rather Chrome supports web apps, and Android allows apps not from the play store, unlike Apple, and yet people complain about both sides.

They'd also complain if Android allowed a loophole to violate privacy by targeting old insecure apis.

Re: Prisoners of Google Android development

#308

Post by rany_ »

imchillyb wrote: post #78
jarm0 wrote: post #28

Earlier quoted context omitted.

Yes, that's definitely one side of the problem and I'm not chasing too much backwards-compatibility. My biggest concern in this particular situation is that there is no way (with Android, at least) to pull-back/cancel/rollback release and everything is blocked behind Google's review process. Why isn't it just possible to "yank" problematic release and continue showing previous release as the latest version. That woul…

Rollbacks allow malicious actors to /simply-easily/ circumvent device security and user preference. To allow rollbacks is to /significantly/ increase the attack surface of a device.

Not necessarily, Google has access to the developer's private key they use for signing their APKs so they could just make a fake release that has a bigger version number than the current version whenever a rollback is needed. No change is needed on Android itself, it's a Google Play issue.

Re: Prisoners of Google Android development

#309

Post by danpalmer »

skinner927 wrote: post #219
danpalmer wrote: post #174

Earlier quoted context omitted.

This is why you set a version number for the API you want. No type system in wide production use is able to encode the semantics of APIs sufficiently. Many of the best APIs out there have version numbers that allow you to pin the API structure and semantics – GitHub and Stripe come to mind with this.

There’s this company out of I think Washington state who builds an operating system for x86 and x64 systems. I know for a fact that GUI applications from 15 years ago still work on the modern version. It’s called Microsoft Windows. You should check it out. The win32 api has changed but it’s backwards compatible.

Windows has "Compatibility Mode" to support these things. Additionally there are layers and layers of Windows API – an app built against Windows XP may still work but it's not using the same tech as one built for the current version of Windows. This is part of the reason that users always had to install different versions of .NET, or part of the reason why Windows is a huge OS (API surface area, disk usage) in a way that isn't suitable for mobile devices.

Yes MS are better at backwards compatibility, but everything is a tradeoff and they receive plenty of criticism for the direction they take.

Desktop computing has different constraints and is moving much more slowly than mobile computing, so it's more feasible to maintain that compatibility.

Re: Prisoners of Google Android development

#310

Post by scarface_74 »

kaba0 wrote: post #287
scarface_74 wrote: post #259

Earlier quoted context omitted.

How would that possibly true? A native app doesn’t go through the three or four phases that a modern JavaScript engine goes through. Especially on iOS more so than Android apps since there is no JVM like environment.

You are saying the same thing (though do note that the “JVM” on android does a hybrid execution with cached native functions)

I see now what the parent poster meant. He said a web app can have lower performance and battery utilization. He meant lower performance and higher battery utilization. From the context it was clear and I misinterpreted it.
Post reply on HN