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 the plugins, which haven't been updated yet, so it ended up being a full weekend of work and testing.
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.
Professionally, we are also scrambling. We have a legacy app that some supported customers are still using until the end of the year. The app is a fairly complex application, and basic testing has already shown that just changing the target api version has broken quite a few things. We have gotten the extension, but we know this will take 1-2 weeks of developer time + 1-2 weeks of QA's time, for an update that does nothing but appease Google. All for an app we are going to officially remove from the store at the end of the year, once all customers transition to the new app is complete.
> 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
My TWA app still got hit with this mandatory update requirement. I'll have to rebuild the wrapper app for the first time in years. I don't even remember how I did it last time but I do remember that Android makes it nowhere near as trivial as it ought to be. I can practically guarantee that something will break if I try to do all this busywork. I'm probably not going to bother, it's just a free app that I made as a side project and a large majority of users visit the website in a browser.
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.
> 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://youtu.be/ddbHp8tGBwQ
I find it much easier to install a web app from the website than having to find anything on the App Store. There’s nothing easier, it’s only 2 taps when browsing the website, at least on Safari. The process is exactly the same as in iPhoneOS 1.0, when this was the only official way to get applications.
The problem is not that it’s difficult, it’s that the share sheet got bloated and should be completely rethought.
> 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 agree with you in many cases. At my professional company, we've made the decision to write native apps for Android, iOS, Windows, and the web, because we have pretty deep integration into each platform and want the best native experience for our users.
But, for my personal apps (which is what I am talking about in this thread), I can't support that. Writing it once and maintaining it takes up enough of my free time. This app also doesn't have any integration with the system, and has a minimal interface, so it works quite well as a web app.
We love to discuss technology on here and I have my own opinions about that, but to be honest, as a user I have found absolutely no correlation between the underlying technologies and how well an app works for me.
It often hinges on seemingly small design decisions that make some frequent task either a breeze or a constant annoyance. There aren't many cases where making the right design decision depends on whether or not the code is "native".
I believe the most important distinction is whether the motivation for making an app is economically aligned with my motivation for using it and sustainably so.
I used to think that, and then I started using Phanpy and Voyager. PWAs can be surprisingly good if they're done well. The problem is the mobile platforms have done nothing to optimize the experience or encourage their development and so the good examples are few and far between.
>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.
I have compassion with you, some of my private apps were also affected.
But we were being told this deadline for many months now.
It was clear that at some point they would show it more in your face.
I also disliked the way it was formulated, also, even if everything was fine in production, it complained when testing versions didn't comply (doesn't make sense).
Also, it was always only about pushing new updates (it's ever year like that). You could still keep the app live for some time.
My understanding from earlier notifications was that updates would not be accepted unless you targeted a new api version. That is fine, since I haven't updated the Google Play "app" since I first released it. This is because the real app is a PWA that I update through the web, and the Play Store app is just a shell around that.
The first time I was aware that the app would be delisted in the Play Store for new devices was in the August 18th email.
Not sure if it helps, but if I was in your situation I’d provide a few app updates with a screen to train users on how to install the PWA version and gracefully run away from these problems. Maybe also provide a some sort of a form to get some feedback over the difficulties encountered by users to get there.
Good luck!
The problem is that many of my users are temporary. For example, I have an app for the public transit system for a resort town in Colorado. The town has a decent, albeit small bus system. They technically have an app from their vendor, although it is not very good and is difficult to find. If you search for "$town_name transit app", it won't show up anywhere, where as my app does. And I think my app is much more user friendly. I wrote it because I visit this area a lot and hated the vendor app.
My users are visiting this town for a few days, and are most likely going to open the app/play store and search for an app, use it for a few days, then leave the town and forget about it. The least amount of friction I can provide the better. My only goal is to support public transit and make it a smoother experience.
I love cordova for my personal apps, but once every year or two when I’m forced to update Android and iOS they become such a nightmare. I spend days or weeks getting unblocked because I don’t have unlimited time to maintain these apps alongside everything else in my life.
Your customers have been using websites for much longer than they have been using apps. I simply don't buy that they can't understand how to use a website. Stop underestimating your users.
It's amusing that you are certain that you know his customers better than he does. I believe that you are utterly wrong, and if not most than certainly many people who use public transport and smartphones have never or nearly never been using websites on their phones, many of them haven't been using websites on a computer two - this is very typical of the non-technical people, especially those who are members of the younger and the older generations.
If his customers are under 25 or 25 probably not. There are also plenty of older people in the US who never had a computer. But they now have smart phones.
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 base, at least not initially. Staged rollouts are the norm and we never initially deploy an app to more than 10% of the user base after a release is published. Additionally, when we finally feel confident with a release, we deploy the app to 99% of our user base and not 100%. The reason for this is, if we need to halt a roll out for whatever reason, we are easily able to do so, so long as the release is not deployed to 100%.
For better or worse, both of these tactics are well-known by more experienced Android developers.
I agree that things could have been done better in many ways. However, as explained, it is a legacy application, which does not see any active development nowadays and it would just not make sense to build such a robust QA. This particular app have been written long time ago by another company and there's not even simple unit tests. That's the hard truth. But still, even as complex setup as you have, there's still going to happen mistakes and the real problem is that there is no way to pull-back/cancel/rollback release.
How would staged roll-out help in this situation for all customers? When end-user gets the faulty version of the app, does he/she have a way of getting the non-faulty version somehow?
Unfortunately, as you noted, the game is rigged and you have to play within the sandbox provided. With that, and as you also noted, your testing simply needs to be better, especially since this is a customer-facing app and not an app that's solely used internally. As for dealing with the rollout when a serious bug is now in production, if you didn't roll out your app to 100% of the user base you could halt the roll out so it wouldn't affect any more customers. Then, while far from ideal, you could ask affected customers to uninstall the app and then reinstall it, and the newly installed version would reflect the previous version of your app.
Just to add, even if you do not change anything at all, you will spend many hours just getting the build environment up to snuff if it hasn't been touched in over a year. Gradle, the plugins (android, crashlytics, etc), the build.gradle DSL, dependencies ... its quick bit rot.
Android as an OS does not support rollbacks. It can only upgrade apps in monotonically increasing `versionCode`s. The simple reason is that client side data may have been upgraded by a newer release to a format that is now incompatible with the old version. Sqlite databases follow the same policy.
This is well-known to anyone who has been doing Android development for a while.
Protip: that field takes decimals too. We always go for 99.99999999% so no users get left out accidentally. But it allows you to cancel a rollout like you say
What you're saying is totally true and the only pragmatic way to update/release. But it is a shame that if the api update compiles you can't expect things will just work the same way.
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.
This is my same sentiment, author has been too dramatic with the blog title. Updating from 30 to 33 SDK is just a disaster waiting to happen. In the mobile world that is just too long.
But this is also kind of a problem created by Google - why force from 30 to 33 and not force from 30 to 31, then 31 to 32 etc? Gradual API level upgrades would make more sense in my world and probably would be less risky for every party.
I don't get the comments tearing into OP. Sure, he could have been more careful. He could have tested the login on the latest version of Android. But what if it wasn't a login crash? What if it worked on the latest version but not others? At what point do you draw the line?
At some point, you just have to say "OK this is a platform used by literally millions of apps and millions of developers, and mistakes will be made, and it should be easy to fix them by stopping your own rollout (without having to know tricks like doing a staged release) or immediately making an older, already approved version live again". It's such a basic design principle to make things revertible/recoverable, especially for something like an app store.
I'm the OP and thank you for thinking along with me here. As stated in numerous replies already then I totally agree that I could have done better in terms of testing things out - of course, there's always room for improvement in that regard. There was a deadline set by Google (again, first time I heard about it was at 18th of August, not before), change seemed trivial at time and since app worked on an old Android version as it was before then I didn't expect it to fail so miserably. Again, I'm not a seasoned Android dev, but have 15+ years of experience in software development in general so I have some expectations how things will work or not and what to expect and be afraid of. I really didn't know that "best practice" is to do a staged roll-out of "99.99999999%" to have a way of partial "yank" possibility of the latest release. To find out that there's no way to cancel/delete a latest release to fall back to previous working version was just something I did not expect in my wildest dreams (I guess this is something you only learn during situations like these). Yes, everyone can blame me for not testing every functionality with every Android version and I do the same, but please open your eyes and understand that the way releases are currently handled by Play Store is not a sane person would do outside of Play Store. Everyone will have a problem like this at one point and I do hope that this article will and thread in here will lower the number of developers experiencing situation similar to this.
but bugs slip testing all the time, that why even “the pros” have to use staged deployment trick, which takes us to the root problem: releasing on android is like running through a minefield.
there are a million “shoulds”. just because you know most of them or can afford to account for them on every release doesn’t excuse google for the maintenance nightmare that the android ecosystem is.
> And having a phase roll out with a rollback is also not a new concept.
Having a quick revert is also "not a new concept". Most modern devops practices focus not just on Mean Time to Failure, but Mean Time to Recovery, and a quick revert is a critical part of that. Even Google's own SRE best practices encourage that.
> It's time to move back to open (web) standards and take control back into our own hands!
Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.
Yeah, that's also true, but at least this kind of problems can be handled by a roll-back or whatnot. Situation we're currently are in does not allow to do anything while we know that bad build is in production and phones are updating to it automatically. That's the worst situation to be in.
Sure, you own the servers so you can rollback. You don't own a user's device. If you want to rollback after a full rollout, all you do is build your new/rollback release from your previously working commit and update your version number.
Typical "legacy application situation where no team is assigned to" here. At least I've never seen in my 15+ year career a legacy application, which has a very good maintenance/testing model in place. It will just not work because maintenance/testing needs also resources and updates, but if priorities are in different places then it's not possible. Of course as stated already multiple times - things could have handled in better ways, but this doesn't mean that Google should not allow to stop release at least. Anyway, lessons learned.
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 binaries to which you’ve lost the source code.
Most people don’t go to that effort and just invalidate old stuff in the name of maintenance, reliability, and security.
Whichever branch cut you take you’re going to cause a problem for somebody. If not, nobody is using your code.
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 would solve most of the issues within context of this problem.
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.
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.
This is exactly how Android works. But because API changes bring privacy and security improvements, scummy software used old compilation targets to abuse backwards compatibility to avoid complying with privacy and security practices.
This is why Play slowly enforces apps to raise their compilation target and implement safer APIs. It's lagging for YEARS after API changes, so there's plenty of time to fix apps.
The OP just decided to be lazy and wait for last two weeks.
There is no best win option, but you can also publish your app separately - these are Play Store requirements, not Android requirements.
It's far from trivial in many cases, and it'll never get anywhere near as much use as the Play Store version... but it is nice to have an escape hatch.
I got the impression the author was mainly complaining about Google's role as arbiter of what software users may run. The problems from deprecating APIs are just what brought the author's attention to how vulnerable we've become to Google's whims.
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.
> 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.
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 be a one-man developer trying to maintain a cross-platform mobile app. I sympathise. But strictly from the sidelines; I long ago decided that I wasn't interested in playing games with proprietary platforms and gatekeepers.
> 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.
Actually, both of those things can easily be done in a browser app.
About the only thing that can't be done easily on mobile right now is GPU compute shaders. But that will also fall when WebGPU merges from desktop browsers.
The only other thing I can think of is generic, system-wide file management. That probably won't ever be coming. Though the File System API does allow users to grant access to specific directories, I don't think the permission persists past a page reload.
> It was always obvious that Play Stores and their captive developer "communities" were a trap. Forced API upgrades are just one aspect of that.
I was convinced the app stores would be a flop because I didn’t think there would be a critical mass of developers that were willing to give up the guarantee they could actually deploy their apps.
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.
But you don't want to be ideological about user sovereignty over their own devices, do you? Be smart and pragmatic instead, and walk the path of least resistance into a cage.
"At Google, our philosophy is that “rollbacks are normal.” When an error is found or reasonably suspected in a new release, the releasing team rolls back first and investigates the problem second. A request for a rollback is not interpreted as an attack on the releasing team, or even the person who wrote the code containing the bug; rather, it is understood as The Right Thing To Do to make the system as reliable as possible for the user. No-one will ask “why did you roll back this change?” as long as the rollback changelist describes the problem that was seen."
As of last year, due to a mix of Google Play policies and Android updates, if you're distributing an app on the Play Store, the only way to rollback is an uninstall + wipe user data.
----
* You cannot downgrade to a lower `versionCode` & `versionCode` is defined by the developer
* Android 11 prohibits writing to 'permanent' storage of the phone, with the exception of media, or using the `DocumentFile` API, which treats a local folder as cloud storage. `DocumentFile` is unusable for many use cases
* A developer can set `hasFragileUserData`, which should ask a user if they want to wipe their data on uninstall. There are Google/Android bugs which mean this dialog may not be shown
* If an app is uninstalled and the user doesn't delete data, Android blocks a downgrade to a lower `versionCode`
* You can use a regular java.io.File if you request `MANAGE_EXTERNAL_STRORAGE`
* Google Play only grants `MANAGE_EXTERNAL_STRORAGE` in exceptional circumstances
I had the same thing happening to a bunch of apps based upon a framework I built. The newer API version had problems with existing dependencies, really a shit ton of work to get back to exactly the same place I was already.
I really respect Microsoft a lot more, where stuff from the 90's has less issues running on the latest Windows version that mobile apps I wrote four years ago on Android.
Readit News
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 the plugins, which haven't been updated yet, so it ended up being a full weekend of work and testing.
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.
Professionally, we are also scrambling. We have a legacy app that some supported customers are still using until the end of the year. The app is a fairly complex application, and basic testing has already shown that just changing the target api version has broken quite a few things. We have gotten the extension, but we know this will take 1-2 weeks of developer time + 1-2 weeks of QA's time, for an update that does nothing but appease Google. All for an app we are going to officially remove from the store at the end of the year, once all customers transition to the new app is complete.
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
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.
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.
Also, Google has made in much easier in recent years to submit plain PWAs to the Play Store: https://youtu.be/ddbHp8tGBwQ
The problem is not that it’s difficult, it’s that the share sheet got bloated and should be completely rethought.
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.
But, for my personal apps (which is what I am talking about in this thread), I can't support that. Writing it once and maintaining it takes up enough of my free time. This app also doesn't have any integration with the system, and has a minimal interface, so it works quite well as a web app.
It often hinges on seemingly small design decisions that make some frequent task either a breeze or a constant annoyance. There aren't many cases where making the right design decision depends on whether or not the code is "native".
I believe the most important distinction is whether the motivation for making an app is economically aligned with my motivation for using it and sustainably so.
It's not primarily a technology issue.
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.
Deleted Comment
But we were being told this deadline for many months now. It was clear that at some point they would show it more in your face. I also disliked the way it was formulated, also, even if everything was fine in production, it complained when testing versions didn't comply (doesn't make sense).
Also, it was always only about pushing new updates (it's ever year like that). You could still keep the app live for some time.
Saying you only had two weeks is not correct.
The first time I was aware that the app would be delisted in the Play Store for new devices was in the August 18th email.
My users are visiting this town for a few days, and are most likely going to open the app/play store and search for an app, use it for a few days, then leave the town and forget about it. The least amount of friction I can provide the better. My only goal is to support public transit and make it a smoother experience.
DOWNLOAD THIS APP.
I'm like: I'm on this website? It's an API call. Make the API call from the friggin' website.
Edit: I'm an idiot. On the screenshot where they refer you to the application it actually shows a URL:
https://sedonashuttle.transloc.com/routes
Enjoy.
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 base, at least not initially. Staged rollouts are the norm and we never initially deploy an app to more than 10% of the user base after a release is published. Additionally, when we finally feel confident with a release, we deploy the app to 99% of our user base and not 100%. The reason for this is, if we need to halt a roll out for whatever reason, we are easily able to do so, so long as the release is not deployed to 100%.
For better or worse, both of these tactics are well-known by more experienced Android developers.
How would staged roll-out help in this situation for all customers? When end-user gets the faulty version of the app, does he/she have a way of getting the non-faulty version somehow?
This is well-known to anyone who has been doing Android development for a while.
Well since it broke, it kinda of would have made sense.
> This particular app have been written long time ago by another company and there's not even simple unit tests
He didn’t do a simple smoke test.
Well that's a lesson you won't need to learn twice, isn't it?
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.
At some point, you just have to say "OK this is a platform used by literally millions of apps and millions of developers, and mistakes will be made, and it should be easy to fix them by stopping your own rollout (without having to know tricks like doing a staged release) or immediately making an older, already approved version live again". It's such a basic design principle to make things revertible/recoverable, especially for something like an app store.
This is a poor excuse. Even if it were a web app, you would still need to test on multiple browsers.
Doing a smoke test on a new release is just basic professionalism.
And having a phase roll out with a rollback is also not a new concept.
there are a million “shoulds”. just because you know most of them or can afford to account for them on every release doesn’t excuse google for the maintenance nightmare that the android ecosystem is.
Having a quick revert is also "not a new concept". Most modern devops practices focus not just on Mean Time to Failure, but Mean Time to Recovery, and a quick revert is a critical part of that. Even Google's own SRE best practices encourage that.
It is inexcusable that for a task to port an app to Android 13 (targetSdkVersion 33) that the app is not tested with Android 13.
Wait till you discover that the web is also half controlled by the company that is causing your problem now (Google). And Apple who owns Safari, the only browser on iOS in the real sense, isn't really your friend either.
I certainly prefer a website to a random app that just exist to better track you. But I read the article more as they half hassed the maintenance ...
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 binaries to which you’ve lost the source code.
Most people don’t go to that effort and just invalidate old stuff in the name of maintenance, reliability, and security.
Whichever branch cut you take you’re going to cause a problem for somebody. If not, nobody is using your code.
This is why Play slowly enforces apps to raise their compilation target and implement safer APIs. It's lagging for YEARS after API changes, so there's plenty of time to fix apps.
The OP just decided to be lazy and wait for last two weeks.
It's far from trivial in many cases, and it'll never get anywhere near as much use as the Play Store version... but it is nice to have an escape hatch.
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.
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.
Only if you are lucky they don't depend on stuff that started being removed after Java 8, when deprecated for removal went into effect.
This is already the case.
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 be a one-man developer trying to maintain a cross-platform mobile app. I sympathise. But strictly from the sidelines; I long ago decided that I wasn't interested in playing games with proprietary platforms and gatekeepers.
Actually, both of those things can easily be done in a browser app.
About the only thing that can't be done easily on mobile right now is GPU compute shaders. But that will also fall when WebGPU merges from desktop browsers.
The only other thing I can think of is generic, system-wide file management. That probably won't ever be coming. Though the File System API does allow users to grant access to specific directories, I don't think the permission persists past a page reload.
I was convinced the app stores would be a flop because I didn’t think there would be a critical mass of developers that were willing to give up the guarantee they could actually deploy their apps.
They'd also complain if Android allowed a loophole to violate privacy by targeting old insecure apis.
https://cloud.google.com/blog/products/gcp/reliable-releases...
"At Google, our philosophy is that “rollbacks are normal.” When an error is found or reasonably suspected in a new release, the releasing team rolls back first and investigates the problem second. A request for a rollback is not interpreted as an attack on the releasing team, or even the person who wrote the code containing the bug; rather, it is understood as The Right Thing To Do to make the system as reliable as possible for the user. No-one will ask “why did you roll back this change?” as long as the rollback changelist describes the problem that was seen."
----
* You cannot downgrade to a lower `versionCode` & `versionCode` is defined by the developer
* Android 11 prohibits writing to 'permanent' storage of the phone, with the exception of media, or using the `DocumentFile` API, which treats a local folder as cloud storage. `DocumentFile` is unusable for many use cases
* A developer can set `hasFragileUserData`, which should ask a user if they want to wipe their data on uninstall. There are Google/Android bugs which mean this dialog may not be shown
* If an app is uninstalled and the user doesn't delete data, Android blocks a downgrade to a lower `versionCode`
* You can use a regular java.io.File if you request `MANAGE_EXTERNAL_STRORAGE`
* Google Play only grants `MANAGE_EXTERNAL_STRORAGE` in exceptional circumstances
I really respect Microsoft a lot more, where stuff from the 90's has less issues running on the latest Windows version that mobile apps I wrote four years ago on Android.
You don't blame Microsoft for Adobe Flash not working on Windows 11 store, do you?