Prisoners of Google Android development
solutional.ee
solutional.ee
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...
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.
Oh, I can say that about a LOT of other Google products.
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
It would be trivial to present the user with a more proactive notification that a site can be installed as an app, or even include such a notice in their search results on Google, but they choose not to do so.
iOS is more difficult since user needs to understand that "saving to home screen" is same as installing "app" and there's no way to trigger it programmatically or help user in any other way than with visual illustrations.
One notably stupid usage of the Share option was (I believe it is no longer how it’s done) adding an image to a hidden folder — that’s something you definitely don’t want to share, yet quite easy to accidentally send to someone during this process.
It literally took a two second Google search
That's not really correct. "PWAs" actually just describe a suite of APIs, most of which Apple supports: https://firt.dev/notes/pwa-ios/.
The biggest "missing link" has been support for push notifications, which iOS 16.4 added: https://www.theverge.com/2023/2/16/23603042/apple-push-notif...
If the app is a valid PWA, it's displayed like any other app on your device. There is no browser UI, it gets its own entry in your app switcher, etc.
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 option and they sucked balls? That never really changed. People still find mobile sites with maps that are impossible to use. They don't expect that from app store apps.
And if it's just a web site, why do you need to "install" it? A link is surely sufficient?
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.
So two of the three parts that are native are there to make it a worse user experience?
Analytics tell developers exactly where bugs and crashes occur.
And on which devices or versions of the OS the problem is.
Without analytics it would take weeks/months to figure out exactly what line of code is causing the issue. Heck, the developers might NEVER KNOW that the software has an issue.
Apps would just keep crashing on users for years. And developers would have no idea why users were abandoning their product.
Nobody that has any idea what they're talking about would say that analytics makes for a worse user experience.
The point is that there are apps that can pretty much be built entirely using web technologies as PWAs, but in doing so they are no longer "just web sites" and they need functionality of installed apps, like notifications. For example, most banking apps on Android could be entirely rewritten as PWAs, but they'd need to make use of things like notifications (I don't want a random website sending me notifications, but I DO want notifications of activity on my bank account) and camera APIs (e.g. for mobile check deposit).
The last thing being the worst as SMS 2FA is so insecure, but SMS of your bank deposits isn't much better.
It basically is just a difference in use case and how most people thing about "apps" vs. "websites". If I have a long term relationship with a business, and I access its functionality frequently, I'd rather have it as an app on my homescreen.
There are benefits to having something installed. You can give anything installed the ability to send notifications.
Having to manage that permission on a per-website basis is way above the tech ability of most users.
But this is apparently difficult for "tech literate" people to grasp.
Maps require complex gestures and advanced graphics and UIs that would never work well as a PWA. Try maps.google.com. Its nothing like the Google Maps app. Plus Android Auto integration.
Tile probably needs pretty deep Bluetooth integration and background processing that the web doesn't provide.
YouTube can do things like PiP that you can't do on the web.
edit: Sorry for the snark. I think that maps are probably doable with pointer events (https://caniuse.com/?search=pointer) and Android is doing pretty well in terms of Web Bluetooth https://github.com/WebBluetoothCG/web-bluetooth/blob/main/im...
If I request the Desktop version of YouTube, where Google doesn't hide their own Mini player button, the video continues to play in the corner.
Mapbox.js is also pretty capable.
Not really sure what you're on about TBH.
Really? You don't understand the value in having the PWA appear as a native app icon alongside everything else on the device?
It's a bit confusing, isn't it? "Add to home screen" makes it seem like you're just adding a link, but it's installing the PWA, possibly enabling notifications, and etc.
1. For people like you that don't want to install them, they're just a normal website.
2. For people that do want to install them for the added functionality (things like notifications), then it is easy to install, and furthermore cheaper for developers to build and maintain (one codebase instead of multiple).
You say "you have no desire to have an app", but I think for most people that's really dependent on the site/application. Yeah, for any site I just have a short term or infrequent transaction, I don't want an app either. But many/most people use apps for businesses they have long term relationships with (namely financial institutions).
In short: most devs' simulacra suck.
Check out:
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.
15 years ago, getting it right took a ton development time, but today there are frameworks that handle it with minimal effort.
And this is suppose to be an argument for web apps?
The WHOLE POINT of native apps is that they are better at integrating with the system. Like access storage, gps, camera, accelerometer/gyroscope, etc.
Besides that the only benefit of a native app is basically that the UI/UX will be closer to what the user is accustomed to.
Especially on iOS more so than Android apps since there is no JVM like environment.
You realize you’re still not exactly making your case for web apps right?
That there are people who have to target multiple operating systems, and don't have 100+ people working on their team, right?
I mean...it doesn't take a genius to figure out that there's a benefit to being able to write code once and deploy to ALL users/customers without having to dedicate entire teams of developers with expertise in various platforms.
I'm an Android developer with 10+ years of experience. I take pride in my native apps that I code for the company I work for. They are far superior to any web app or "multiplatform framework solution".
But if I had to create my own personal app, there's no way in hell I'd spend years learning everything it would take to create a native iOS, Windows, Linux, MacOS version.
I'd be an absolute idiot if I didn't just choose a solution, like a web app, or framework that was able to output for more systems, etc.
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.
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.
> Apps with a target level of Android 11 (API level 30)* or lower will not be available to new users running the Android OS higher than apps’ target API after August 31, 2023. >Apps with a target level of Android 10 (API level 29) or lower have not been available to new users running the Android OS higher than apps’ target API after November 1, 2022, or May 1, 2023, if your app had an extension.
If you never heard of it you've been deliberately playing dumb.
I usually work on the backend and/or front end (Web). This is a pretty new world for me.
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.
Do people really search for entirely temporary/short-term/single-use use apps, like for a resort town's transit or a restaurant? For me it's a last resort thing, if there's no website or it's unusable.
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 very limited use, like the transit of a place they'll visit once for a few days at most (especially considering there's Google/Apple Maps, Citymapper Transit; unless you can buy tickets through the app it's a waste on top of a waste). Has it been ingrained to such an extent that phone == app? Or is that an iOS thing, or maybe an American thing?
Most of the people writing on HN were first exposed to the internet through web browsers. On the other hand, children these days who grow up with smartphones first interact with the internet through phone apps. Do they have any difficulty adapting to the unfiltered web when they grow older?
Just the simple trick of zooming in on a website with a "2 finger pinch/pull" is something a big part of the population doesn't even know how to do. I know my mom would probably just give up.
Buttons on many websites are way too small for some people to use.
Those are never an issue on native apps. The UI on apps scale with the size of a phone's screen. No matter if you have the smallest iPhone or the largest Android.
This alone is enough for many people to not use the web browser unless absolutely necessary.
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?
About better testing - there's always room to improve testing, but no way it's going to happen with a legacy application where no active team is assigned. Only these irregular updates mainly forced by Google are done. Unfortunately.
This is well-known to anyone who has been doing Android development for a while.
Each track in Google Play (alpha, beta, canary, prod) can hold up to one release at a time. It would get really confusing if it allowed more than one. And with the other rollout safeguards provided decelopers, it’s quite possible and very easy to do exactly what you’re asking for.
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.
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.
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.
Same thing if your site cert expires, or browsers start blocking specific functionality/code/tags. Seems like they just want to complain about the thing they aren't familiar with.
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.
There has been zero communication towards me from Google until two weeks until deadline. Yes, maybe if I would have logged into Play Console then there might have been some notifications, but there have been no reason to do so until that e-mail (I'm usually not involved with Android projects, otherwise I might have noticed similar warnings via other projects early on).
Maybe it's possible that different roles in "Google Play Console" will receive different type of messages at different time? I'm not an admin for that app and it's possible that someone else has gotten prior warnings, but might have ignored these, because usually they are not with technical background.
But it's true that the first notice was sent months before the time limit, so he might have missed previous warnings.
But nice of you to assume he's lying. /s
Though unfortunately from time to time they also do break power user use cases…
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.
Plenty of libraries from that era didn't require unsafe code to accomplish their tasks.
I'm more than happy if google decides to break people who used non-public android apis.
Just browse the JEPs and release notes.
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?
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 app shops that work according to fire and forget.
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.
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 update the apps, if he can find what they are looking for through billions of game apps and very similar apps that are only published to send advertisements to the user or to collect his personal data.
Disadvantages:
1. you are tied to the whims of the app store manager
2. You have no control over the app publishing process: You cannot decide if you can publish your app or not, only the App Store Manager has the power to decide when and if it is convenient for him. I think only the user should have this right.
I'd prefer to install the native commercial native apps (for example, the home banking app) on my phone by downloading them from the developer's website, in a private area that I have to access with my credentials, where the app is GPG signed and I can check the integrity of the package. An auto-update feature is doable.
For open source apps, there is the F-Droid store where you can add your own repository (a bit technical and not for everyone, I admit : pre installing F-Droid on the new phones could help a lot, but I don't think Google will ever allow this).
Another viable option is PWA. In my opinion, there are very few apps that need the native features, for all the others, almost everything is now doable with PWA technology, and you do not have to bother sending updates to users or asking them to upgrade.
The monopolistic and commercial app stores, with the excuse of making life easier for users and in a supposedly "better security", are a "wonderful" way for Apple and Google to make billions on the work of independent developers and, in the case of Google, to collect and sell personal data about users and to sell ads of any kind in any way.
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?
Hard to disagree with that.
When "support" is hoping that HN or Twitter attracts helpful attention, we're going down the wrong path.
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.
Partially release to your users and monitor the health of the release as it trickles out. If everything is fine then increase the percentage.
Only very late increase to 100% as then there is no going back.
Google has been putting out these warning messages for a while, and any decent Android developer should know about target SDK versions.
Didn't test the app on the platform they were updating to?
Didn't function test the app on a physical device that surely had on hand?
Somehow this is Google's fault?
I dislike the stronghold Apple and Google have as much as anyone else, but this is just shoddy maintenance and you've effectively advertised that your "agile software company" can't update an app without proper process, lack the ability to keep on top of well-defined changes within Android app development, and to top it off have the gall to claim Google is being unprofessional?
Solutional is an *agile* software development company
The point being made by the author is that the app didn't actually need maintenance as far as its developers or users are concerned, which is a fair and reasonable complaint.
With near perfect backwards compatibility, the amount of software that society can consume is in effect unlimited. The number of software developers is finite, but the amount of software they can create isn't: only the growth rate is finite. Thus society can benefit from an ever-expanding library of programs which increases overall wealth. Indeed, tool creation is the only way to increase wealth in countries with a flat or falling population (productivity * population = gdp, more or less). In this mode, software is like knowledge. It accumulates and compounds.
With imperfect backwards compatibility you are forced to engage in continuous maintenance of all existing software. Suddenly there is now a fixed limit on how much software society can have, it's a function of how many maintenance developers there are. You can literally reach a limit where things can slide backwards. Problems can become un-automated. In this mode, software is more like oil. It can run out.
Google want to force continuous maintenance because the Android team justify their existence with constant change, and if a platform is full of unmaintained apps then it will feel old and tired compared to a platform full of apps that have the freshest new looks and features. But that often doesn't matter, especially for non-consumer or specialized software used only by a small number of people (but for high leverage impact). Because Google and Apple are unapologetically consumer focused cultures, they care far more about things like how apps look and stuff that's irrelevant in business contexts (consumer privacy).
Anyone who has already "purchased" (may be free) the app will still be able to access it, and anyone on an older device can still access it.
I the simplification of this that you specified is ok as a summary, but the devil is in the details, and the details here do make this policy much less impactful than your summary suggests.
Policy: https://support.google.com/googleplay/android-developer/answ....
> There's nothing we as developers can do to speed up the reviewal process nor contact Google support in any way. There are no possible workarounds and we just have to wait. Wait until we're excused to put our fixes to production.
A couple years ago, and out of self-learning process, I decided to develop an Android app, never did any smartphone app development, Flutter was new so got excited to try it out, long story short, I submitted the app to play store, and it remained “under review” for 40 days! Just like OP, Next day I was checking the dashboard, silly me thinking the process is smooth, after 3 days I stopped checking and later forgot about it until they sent an email after 40 days, I pulled the app later and decided never to touch anything again with smartphones app development, and that was play store, supposedly the easier one after reading some horror stories of the App store.
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 a few POP3 servers and then I'll download those messages on my laptop (Thunderbird)
OSMAnd, offline maps and trop recording. Can't be web based.
Password manager, with a local dB synced with Syncthing.
Syncthing.
Epub reader, from files stored on my phone.
Photo gallery, for files on my phone. I backup to my laptop with Syncthing.
Banking apps, that I must use for 2FA in the web sites of those banks.
A network scanner, useful to debug networking issues.
Etc.
Of all the apps that are currently installed on my phone the ones that could be web apps are:
Go4Go, to view game records of pro games.
Elementary.
Chwazi.
But they would indeed ask for all kinds of permissions. And K9 and the network scanner would get a really scary-looking permission dialog.
There's no reason this couldn't be browser based.
Before you say "just download the code to your phone as a file", I'm going to assert that's exactly what an app is ;)
Any crashing build will be approved instantly, and the next build won’t be approved for days.
> Today, as part of Google Play’s latest policy updates, we are taking additional steps to protect users from installing apps that may not have the latest privacy and security features by expanding our target level API requirements.
Starting on November 1, 2022, existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level. As new Android OS versions launch in the future, the requirement window will adjust accordingly.
[1] https://android-developers.googleblog.com/2022/04/expanding-...
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 the "new" Android version
So normally there should be plebty of time to prepare. However, if you're an indie developer or not actively maintaining the app, then it definitely is annoying, since usually the apps would work perfectly fine on the new Android version without updating the targetSdk version.
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.
This is just incompetent planning.
There’s also a breaking change coming up in SDK 34 around exact alarms.
Google seems hell bent on making the platform more and more restrictive as time goes on because they started with no restrictions.
Apple started off more restrictive and then loosened restrictions as they put actual thought into APIs.
I don’t think there’s been a breaking change since iOS 8 or so.
If they decided, the app was really not worth it, they could have unpublished it. However, even unpublished apps can jeopardize your account's standing by running afoul of a policy, which Google may have concocted long after the app was written.
Unpublished apps in this state can get your account permanently banned.
You have to support your apps for the rest of your life (if you care about your account).
In this type of environment, you need to ensure every release is as rock-solid as possible. For our extension, we have beta extension with a sub-group of opted-in users that we test on for a week or so before doing a production release. Then we roll out the extension to production incrementally starting with 1% of users and slowly ramping that up to 100% (it seems Android has a similar staged rollout feature).
Hackers and scammers get more advanced. Vulnerabilities are discovered with time.
Users expect more security today than 10 years ago.
For Google & device manufacturers to be able to guarantee that level of security, they need to keep their store updated. And the apps on there shouldn't be using outdated insecure APIs.
If you're not able to keep up with that, then you shouldn't have any expectation of getting new downloads on their platform.
Anyone knows the impact of not updating on time? Google’s message seems conflicting.
It's very mixed. Some haven't received a warning.
Some have a warning that no updates can be published.
Some have 2 warnings; one that no updates can be published & one that it won't be available to new users.
If you target SDK < 33 then you need to update to SDK 33 because you won’t be able to make releases with the old target SDK anymore. (Existing bundles are fine). If you miss the deadline it doesn’t introduce further enforcement than that but it might mean if you had an urgent update you’d need to update the target SDK at that time. So sooner is better.
Both have extensions available to Nov 1.
Wear has different thresholds.
Hopefully https://support.google.com/googleplay/android-developer/thre... helps clarify too.
However out of 30 clients, we also have one app receiving no warning at all.
If you think developer libraries provided by Google for Android are stable, battle-tested and you feel this is akin to first-party "platform code", please be advised that it can be a hellscape with you fighting Google's build tools and the IDE/dev env on one side and zero help on SO to debug device-specific issues with lengthy stacktraces on the other. You end up landing on an Android issue-tracker where some kind soul mentioned the device name, only to find that issue in limbo asking for a working reproduction.
If you don't believe this is a deeply ingrained culture problem, try proposing to your manager "Hey, this software is already really good and customers love it. Let's make this version the last one we release. We can work on something new." See what they say.
This description is rather an argument that this problem is deeply ingrained in management culture, and not in software culture.
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.
This also makes me wonder, was the app already crashing on Android 13 before updating the target SDK version? I suppose the backwards compatibility layers must've kept the app alive on modern phones?
Personally, as a user, I like that Google forces developers to update their apps, because the old API designs were terrible for privacy, but they won't be enforced unless devs update their targetSdk. Breaking installed apps is not an option, but forcing the issue in Google Play works well. I'd also say their testing times were reasonable, if it weren't for the fact that they don't see obvious problems such as "app was never even tested on Android 13".
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 similarly build an expectation of new devices being problematic/best-avoided. - QA burden increases for split behavior *forever*. - The play store becomes an integral element of the privacy and security picture of the device, something that should be the OS’s job.
What would I rather? I’d rather an API evolution plan that doesn’t rely on targetSdkVersion as a means of controlling behavior of APIs. It’s an attempt to have one’s cake and eat it, too, and it clearly falls apart, anyway.
I’m wary of any plan that basically amounts to needing people from other companies to do something in order to succeed.
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 of notifications (requiring explicit permission) is also a godsend.
Google hosts and distributes apps effectively for free (let's be honest, how many Android users actually even pay for apps). The least you can do to keep the app running is to make it work with the modern API once every three years, with an announcement about the API bump requirement a year in advance.
Before Google did this, the Play Store was filled with crap from the Android 2 era that crashed on startup. Paying the one-time $25 developer fee and chucking an APK over the wall isn't exactly a good way to create a decent app store.
You don't have to comply with Google's desires if you don't want to, but you'll have to host the APKs some place else. Termux has had to do this, unfortunately.
Apps that don't get updated can't be easily installed on new devices. They'll still work and be easily installable on old devices (matching the targetSdk version) in case you rely on an Android 9 tablet embedded into your POS.
I think it's entirely fair to expect a yearly "is everything still okay" check from application developers.
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.
It definitely can be with scale. Distributing a 33MB app: Google says they've served 70TB, and this would be 170TB without their optimizations
That also equates to over 5 million downloads.
I'm guessing this app is likely pulling in a lot more than $700 for google.
10MM+ downloads on the Play Store (Unsure if Google gives us actual figures on the dashboard)
As for the developer in the story, he could've just make this a .pkg to be sideloaded by their clients, circumventing Google altogether.
If there's some (ex)-Googlers who could help to speed up update approval process then I would be really helpful, if not then let it just be as a warning for anyone else being involved with mobile app development.
That said, automated regression testing, target environment deployment tests, and beta application groups are your friends. Yes, they cost money/time, but escapes are the Jack in the box cost of not having them.
App Stores and their procedures are a risk to public health. Period.
By unprofessional, is he talking about his failure to test a build intended to run on the latest Android devices, on the latest Android version here?
If not, I don't understand the problem, one shouldn't expect others to prioritise reviewing their work especially as a build already had attention within 24 hours (initial review).
I hope he took this as a lesson learned to adequately test production code for an environment he really has no deployment control of or final QA sign off.
I honestly cannot decide which is worse: app development, or the web ecosystem as a whole. But at least on “the web” you can push fixes at a resonable speed.
Unfortunate for devices like boox ultra or the c version which were launched this year but unlikely to ever be upgraded to 12+ probably given SOCs.
Should have learned - instead I kept updating on the treadmill until a few years ago luckily got a web gig and never looked back.
Not really consolation, but interesting to note.
First of all, new versions means its covered by improved security & privacy functions. Everybody should always upgrade to highest possible version. Google has nagged devs about this for YEARS.
Also, if you never update your app and consider it "done", you are probably ignoring security erratas in your libraries
Finally, who maintains an Android app, makes a major upgrade but doesn't have an Android phone to test it before pushing the update??
I want to figure out a good cross plat strategy but would not want to ever deal with Play and Google.
Perhaps this is an example of "anti-rollback technology".
https://news.ycombinator.com/item?id=37218265
"I personally have been against developing mobile apps for years now for the exact same reasons described in here and other similar articles - as soon as you decide to develop mobile apps then you give control of your product/service away to a third party, which you can't replace when problems happen."
What is an "app store". Computer owner cannot install any software they want on their own computer. Computer owner must select from pre-approved list provided by third party. The word "store" is misleading. 95%+ of the programs in the "store" are free. If the figure 95%+ is incorrect I apologise; I can get the exact figure. This has been publicly disclosed in litigation.
These concepts can seem outrageous to anyone who has watched computer and internet use go from uncommon to common. There are HN commenters who want to pretend they are totally organic and perfectly fine. Hypernormalisation. Beyond question. Right.
Maybe for those who were born into a world where computers and the internet are being dominated by a handful of online advertising services companies calling themselves "tech" companies, ideas like
(a) "you cannot use a previous version of this software that you got for free or paid for; an advertising company will protect your privacy" and
(b) "you must select from the following software chosen by an advertising company to run on your computer"
are an easy sell.
Those born into this hypernormalised environment are actually a minority of the population in the USA. For example, 66% were born before 1999.
https://www2.census.gov/library/publications/decennial/2020/...
We can change this "anti-rollback" and "app store" BS. (All falsely justified in the name of "security" and/or, ironically, "convenience", two mutually exclusive concepts.)
The personal computer belongs to the person who bought it. They can use any software they like, any version they like, and they can write their own software to run on their own computer, without any payment to a third party. This was once where things were before the so-called "tech" companies threw a monyewrench into the wheels of progress.
I fully switched to iOS due to unprofessionalism from Google. IMO Apple does a far better job of QA and backwards compatibility story than Android.
I can say this for sure since I’ve worked at both companies after being a consultant for both Android & iOS.
Lol, maintaining the app provides "no business value." More like "If it doesn't come from above, it doesn't exist."
The new digital jail model is based on open source grotesquely and absurdely massive and complex software (and more and more private protocols), SDK included (c++/java syntax).
Defense: simple and modular software(SDK included, write simple and plain C, not c++)/protocols, but able to do a good enough job, stable in time. Benchmark: not 47398437829 modules, and each modules could be coded by one normal developer in a reasonable amound of time.
Ideas: to move from one module to another, proper URIs: irc[s]://|ircs:,mailto://,http[s]://,etc. We miss a really simple video/audio conf protocol, I mean REALLY simple (TCP based). Crypto-based authentication and end-to-end crypto will add a lot to do from those client programs to make it easy to use.
We can imagine a One Desktop Application handling most/all of them, optionally deferring some protocol handling to external apps (Basically, what is doing current web engines the wrong way).