121–130 of 318 posts
I’m still working on the updates. Was quite a lot of libraries to update for us. And only got the warnings last weekend. Anyone knows the impact of not updating on time? Google’s message seems conflicting.
Wear has different thresholds.
Hopefully https://support.google.com/googleplay/android-developer/thre... helps clarify too.
Earlier quoted context omitted.
> 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…
> And if it's just a web site, why do you need to "install" it? A link is surely sufficient? Really? You don't understand the value in having the PWA appear as a native app icon alongside everything else on the device?
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 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 fixes. The very nature of running such code is one where you are constantly recompiling the bytecode.
Just to paint how absurd this position is for google. The JVM can still, today, execute and use classes targeting Java 1.0 (released in 1996).
This isn't a security issue, this is a "google doesn't want to support the platform" issue.
I'm more amenable to google clamping down on artifacts containing natively compiled code. However, a blanked "Your app was built targeting an old version of android, we won't support that anymore" is just ridiculous. Seems like a way for google to prune old apps from the store more than anything else.
Especially since a policy like this is by it's nature one that shifts a large maintenance burden on android developers. After all, if you want the widest support for your application, you target the oldest version of android possible. Very few people target the latest version of android for fear it will lock out too many of their customers.
If google was serious about security and making the latest android tech widely accessible, then they'd work towards decoupling the android runtime from the operating system version. There's no reason ART and the Dalvik runtime couldn't be distributed via google play like the rest of the android ecosystem. Removing the silly "you need android 17 to do this... opps your hardware manufacture isn't updating their hardware drivers."
But then, that would cut into new device sales and we can't have that.
Earlier quoted context omitted.
> 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…
This isn't true for all apps, but with the notable exception of games, I'd say it applies to most: banking/finance apps, social media apps, travel/airline/booking apps, etc.
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…
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. 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 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…
If Google actually cared about getting PWAs into the store, the process would be as simple as submitting the URL of your PWA manifest to the Play Console.
Earlier quoted context omitted.
As a user, I’d rather that Google make stable and coherent APIs the priority. If the strategy is: 1. Make breaking API changes, but gate them behind the targetSdkVersion. 2. Force app devs to lift the targetSdkVersion to stay up to date by gating device access in the store. It has a few effects: - Developers can be slow to move. There will be zero million new addressable endpoints initially, and customers may similar…
The stable and coherent APIs Google wanted to make all the way back in Android 4.4 was met with strong resistance by power users and data collection companies. Many API changes are either extremely minor ("set this flag if you want to keep the worse, legacy handling behaviour") or extremely important ("actually ask the user before you drain their battery tracking their location in the background"). The new handling o…
Google rakes in money from all the in app sales, store sales, and subscriptions. Further, google is often the provider of in app ads. Not to mention all the money they get from advertising with google searches and adwords built into (practically) every android device.
And, let's be frank here, a 1, 20, 100mb APK isn't exactly a huge amount of data to host. Especially since there's almost always a linear correlation with the popularity of an app and the amount of revenue google makes from that app.
They aren't exactly operating a charity here. The least they could do with all this money flowing in is support backwards compatibility on their platform.
While I concur with the author on the challenges of Android development, the author made two major mistakes. One, he didn't test his app on the latest version of Android. This a very major mistake and the reason why we keep 11 virtual machines around with all the versions of Android that our app is supported on. Two, when you release an app on Google Play, you never, never, never deploy the app to 100% of your user b…
Which is fine, if that's what you have to do, but at the end of the day I really do wonder what their 30% cut of your revenue is for, then.