My account got closed for inactivity while I had multiple apps published. Google does not understand the concept of a finished app apparently, and requires you to continuously push updates or else you permanently lose your account with no way of reopening it.
I don't think cron can write code. Jokes aside, I suppose you could just alternate between two lines of code and just publish alternating patch versions. What a stupid situation, fuck Google.
Exactly. Think Google/YouTube pulls this type of stunt to fully seize user information and data, so that they can do whatever with it.
Giving users true recovery mechanisms, means possible removal of all or part of the collected data. Where sudden or out of the blue seizure and complete removal of the user's ability to access or recover, means it's now all their data.
I have just one app I published way back in 2014 or so, and I think there were only 2 updates (only counting changes that required uploading new builds) since then that were like "do this or we're taking the app down".
One of them was requiring a privacy policy, even for a fully offline game that doesn't even have the internet permission. The other one was having to update the target platform version if I remember correctly.
That has nothing to do with what I was saying on my comment, and there is a reasoning on Google and Apple's attitude, it isn't only money grabbing.
For starters, there are many "done" apps that are like Swiss cheese in terms of security.
And that would have been fine, if Google hadn't tried to shove the Google Play Store ecosystem down everyone's throat by throwing up barriers for side-loading apps and such.
When APIs get replaced they won't work anyway.
People love to bash how Microsoft manages Windows, yet they keep forgetting that Microsoft is one of the few OS vendors that actually keeps the APIs around, instead of having a deprecation process, finalised by actually removing the APIs, or hard forcing the new behaviour.
I do like the concept that developers need to put in some effort to keep the app in the app store. Otherwise there'll be millions of orphaned apps and thousands with duplicate functionality.
By mandating a yearly effort the number of apps will fall through attrition and your app stands a bigger chance to get noticed.
Brett Victor’s Earth Primer, one of the most fantastic educational app for Earth. The team has long ago disbanded, so - let’s delete it without trace? Seriously?
You're right that a policy like this favors newcomers. Buy why is being "old" and/or "done" seen as bad in software? We need more developers to embrace "done" and stop changing software for the sake of changing it. Most of the software I use, I like just the way it is. I don't want more features. I don't want the UI to change (again). I don't want AI and chat in them. I don't want to have to upgrade my operating system just to keep using them.
they aren't asking to make changes. It is android is constantly evolving so basically their 'hope' is every app developer will rebuild with latest android and test on a modern device and proactively fix or remove an app if it doesn't. Plenty of apps crash on startup and not a great user experience to be the consumer that finds the crash so pushing it back to dev to do this yearly is a reasonable expectation.
I don't think it's reasonable to change an OS in such a way that apps which did not previously crash on startup now crash on startup. Unless there is some huge change, like moving from one CPU architecture to another, apps should not even have to be rebuilt, let alone modified, just to keep working year after year.
>Unless there is some huge change, like moving from one CPU architecture to another, apps should not even have to be rebuilt, let alone modified, just to keep working year after year.
And, as history teaches us[0], not necessarily even then.
It's not about newcomers. You merely need to update the API level which is something you can do in a few hours. It's mostly an update of the app version, retrieve the SDK for the API level, recompile and go through the motions in the Play Store.
You don't need to add features if you don't want to.
I do like the concept that developers need to submit to yearly flogging to keep the app in the app store. Otherwise there'll be millions of orphaned apps and thousands with duplicate functionality.
By mandating a yearly punishment the number of apps will fall through attrition and your app stands a bigger chance to get noticed.
bramhaag · · focus · HN ↗
vrganj · · focus · HN ↗
ur-whale · · focus · HN ↗
Sounds like a perfect job to automate by an always-on LLM.
heckelson · · focus · HN ↗
fortyseven · · focus · HN ↗
maybewhenthesun · · focus · HN ↗
Teever · · focus · HN ↗
baranul · · focus · HN ↗
Giving users true recovery mechanisms, means possible removal of all or part of the collected data. Where sudden or out of the blue seizure and complete removal of the user's ability to access or recover, means it's now all their data.
realharo · · focus · HN ↗
One of them was requiring a privacy policy, even for a fully offline game that doesn't even have the internet permission. The other one was having to update the target platform version if I remember correctly.
WA · · focus · HN ↗
zx8080 · · focus · HN ↗
They do! They just hate it.
reddalo · · focus · HN ↗
pjmlp · · focus · HN ↗
Apple does the same thing.
Alternative are having applications in 2026 that use POSIX like in UNIX System V, or Win32 like in Windows 95/NT 3.51.
weikju · · focus · HN ↗
If only……
pjmlp · · focus · HN ↗
m4rtink · · focus · HN ↗
pjmlp · · focus · HN ↗
For starters, there are many "done" apps that are like Swiss cheese in terms of security.
jsiepkes · · focus · HN ↗
And that would have been fine, if Google hadn't tried to shove the Google Play Store ecosystem down everyone's throat by throwing up barriers for side-loading apps and such.
rbits · · focus · HN ↗
pjmlp · · focus · HN ↗
People love to bash how Microsoft manages Windows, yet they keep forgetting that Microsoft is one of the few OS vendors that actually keeps the APIs around, instead of having a deprecation process, finalised by actually removing the APIs, or hard forcing the new behaviour.
<a href="https://developer.android.com/guide/app-compatibility" rel="nofollow">https://developer.android.com/guide/app-compatibility
hn_submit · · focus · HN ↗
By mandating a yearly effort the number of apps will fall through attrition and your app stands a bigger chance to get noticed.
tim333 · · focus · HN ↗
hn_submit · · focus · HN ↗
tomaskafka · · focus · HN ↗
<a href="https://earthprimer.com" rel="nofollow">https://earthprimer.com
ryandrake · · focus · HN ↗
clifdweller · · focus · HN ↗
ryandrake · · focus · HN ↗
nobody9999 · · focus · HN ↗
And, as history teaches us[0], not necessarily even then.
[0] <a href="https://en.wikipedia.org/wiki/P-code_machine" rel="nofollow">https://en.wikipedia.org/wiki/P-code_machine
pyrale · · focus · HN ↗
*: Conditions may apply.
hn_submit · · focus · HN ↗
You don't need to add features if you don't want to.
pyrale · · focus · HN ↗
By mandating a yearly punishment the number of apps will fall through attrition and your app stands a bigger chance to get noticed.
gloosx · · focus · HN ↗