From a cursory glance, their apps seem to be of the kind that don't need continuous updates and can be considered complete. Self-contained, offline software that serves a specific purpose: https://search.f-droid.org/?q=SECUSO&lang=en
Unfortunately, Google no longer recognizes this as a valid development strategy. If you want to publish on Google Play, you need to continuously release updates targeting an SDK released within the past year[0]. If you don't, they will send you constant warnings about how your app is violating their policies, they might derank your app, and eventually they'll stop making your app available to new users.
Updating the SDK is not that simple and it often introduces new bugs if you don't read through the full changelog and test thoroughly. I have 3 apps and it already feels like I spend too much time each year updating SDK, I can't imagine updating 30.
They talk about how this somehow improves security and enhances user experience, meanwhile this policy worsens user experience by pushing people towards ad-filled apps that have the resources and courage to release needless updates, and they still publish spyware on their store.
I've attempted to make this point to proponents of the walled gardens as a real benefit they are losing. There are app developers that just want to make useful stuff and share it. But Play (and the App Store) are completely designed around developers that are trying to make a living there (because that's how Google/Apple make money off the store). As such, the stores are quite hostile to community built software that changes rarely. This is a real loss, as I think that software is often the best available for a given purpose due to simplicity, privacy, and longevity.
I've had some thoughts in a similar vein, but I was thinking from a privacy perspective. The Google and Apple arguments for the walled gardens basically boil down to "You can't trust other stores to protect your privacy and security", but the obvious counter-argument to that is that other stores may actually be able to focus more on privacy and security than the walled gardens do.
Apple and Google inevitably have limited privacy protections, because they'd probably run off Meta and a bunch of other really popular / in-demand apps and cut into their own bottom-line if they really cracked down. In contrast, a third party store may be more free to only host apps that are more privacy-oriented or have been security audited, etc.
Great point, and also: the walled garden operators don't make any money off of free apps, so they don't prioritize supporting creators of free apps. The result is that it becomes unsustainable for most developers to keep a free app on the store.
The incentive structure of walled garden app stores encourages the proliferation of paid apps for everything, including things like an instrument tuner or a notepad app that'd be free in a non-walled garden environment.
> "Additionally, the app prevents devices from taking screenshots."
Why do the "security" apps ALWAYS have to have this anti-feature? It's especially annoying when employed by the banking apps.
Famously, Schwab had some issues where it didn't properly keep track of orders during highest loads (people ending up selling more shares than they had even in IRA accounts), yet conveniently they prevent users from taking screenshots of their app, so you wouldn't be able to prove that you did cancel or replace the order and did receive the cancel confirmation, before it executed anyways. Of course, if it's an IRA account, selling more shares than you own, is clearly Schwab's bug, but not being able to keep these things locally, is one of the biggest anti-features of modern apps.
> Why do the "security" apps ALWAYS have to have this anti-feature?
Every pen test I’ve seen for mobile apps has always had this as an item, even when it’s completely unjustified for the type of app. It’s on their checklist and they will always flag it to show they are doing their job. If you don’t have anybody in the team who is willing and able to say no to a pen tester on a security matter, this kind of thing will happen.
At a previous employer of mine, it was common to share dev accounts for certain things. These were not security sensitive things. They were there purely for dev purposes and these were things like anayltics tools and stuff that the software being built had to integrate with, so they were basically development sandboxes.
Many of these tools had MFA enabled and so it was common to share MFA codes on Slack because the MFA code was sent to an email address that only one person had access to.
One lunch and learn a group of developers shared how they solved this problem by having the MFA codes pushed to a device that was effectively an on-prem server / dev box that they installed custom built software on to take a screenshot of the MFA code and broadcast it on the relevant Slack channel.
The main point of the lunch and learn, however, wasn't so much to share the tool that they had built, but to talk about how they got around the Mac OS security protections that are there to prevent this sort of thing.
My first thought was "we've just written malware."
I'm specifically responding to this sentence of yours:
> It's especially annoying when employed by the banking apps.
After my experience with that MFA code sniffer ... I know exactly why banking apps and other privacy/security-centred apps prevent taking screenshots :)
a) I cancelled my "intelligent advisor" accounts (which was a pain to do by itself) and had the money xferred back into regular IRA accounts. After this was complete, I was no longer able to see any trade history for the past 12 years of those Intelligent Advisor accounts, *even though they were ostensibly backed by regular Schwab IRAs*, and my historical "wealth" tracking in Schwab made it look like I'd simply never had the $NNN^n that was in those accounts for that period of time, or in other words as if I'd added $NNN^n to my accounts on the day of the transfer. Definitely some hackery there. I had one Schwab rep who acknowledged this as a (rather severe) problem, but the other 3 I spoke to did not even understand why it was an issue.
That's a very shallow protection. Even if one has no other camera (phone, table, a real camera) there are always friends and relatives that can help and take a picture of the screen. Furthermore a picture of the screen and the phone around it has a more real feel than a screenshot that could be photoshopped.
Yeah, SDK updates are a pain. I wrote ChromaDoze in 2010 so I've gone through several. Recently, the most annoying changes were:
- Foreground services used to require a persistent notification, now they're not allowed to have a notification unless you prompt the user. So I added a button to beg for POST_NOTIFICATIONS permission, but now permission can be granted after the service starts, so I had to build some magic to make the service refresh its own notification.
- Gesture navigation steals user input when swiping on the left/right edges of the screen, so I had to build some magic to automatically make my UI narrower when gesture navigation is enabled. Drawing apps can't really use setSystemGestureExclusionRects() because it's limited to 200dp.
- By default, apps now render edge-to-edge vertically, behind the semi-transparent status bar and bottom navigation buttons, so I had to build some magic to avoid those areas.
Now that gesture navigation is the default, many developers aren't testing with 3-button navigation, so I've noticed apps where I can't interact with the bottom because it collides with my navigation buttons.
> - Gesture navigation steals user input when swiping on the left/right edges of the screen,
Well I've seen even 1B+ dl apps failing to handle that (on a Google Pixel), so at this point I'm putting the blame on Google. I've switched back to three button navigation. Though even some trivial OS gestures like screen unlock fail reliably on my Pixel 6a. (As in, I do the gesture, it fails to register the gesture, i try to make the gesture "with more conviction" through the whole screen and it still fails, and after few minutes it ends up okay somehow)
I also share this resentment. It became very hard to have a niche app for a family or a small circle. Not like it was easy before, but amount of time one needs to invest to keep it up to date with requirements is not sustainable. Web apps are also a hard thing once you consider hosting and storage expenses.
I think both of you and TFA misunderstand what the targetSdkVersion is.
If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest once per year and push the update. That's it. You're not updating SDKs or compiling against a newer SDK or anything.
I find this kind of posting deeply ironic, since HN and ArsTechnica has been ripping Android a new one before this policy came into effect for allowing apps to exploit old APIs for stealing data, triggering popups, spamming notifications and many more changes that have been done from there. Many praises were sung to superiority of iOS and their demand to keep up to date with new policies and even new design.
And now we hear complaining again over things like... (a few posts lower)... having to implement permission dialog to show notifiactions? Right :D
The reality of the situation is that without required SDK changes, every single app - from your banking app to every game - would STILL demand access to all your files, all your documents, all your photos (and their locations) before they run. And then proceeded to spam you with notifications from background trying to sell you crypto.
Fixing those things unfortunately means that also the opensource developers need to move their behinds and implement APIs in a way that respect users more.
So just don't let developers push updates targeting old SDKs? Show a scary permission dialog on every app launch for dangerous permissions? Delist only the apps that actually use or at least register those permissions?
There are many possible solutions and none of them are "you have to recompile once per year or we ban you".
Sites like HN are different people with different opinions posting different views, so of course some of that will conflict. I don't get why this staggeringly obvious fact needs to be explained over and over again...
And beyond those things there are often performance / battery optimization related things as part of the update too. Just because an app claims it respects your privacy, it doesn't mean that it is a well behaved app.
Most other android app stores enforce a high target sdk. Fdroid is the only one I know that doesn't and allows apps as far back as Android supports. Android has been yearly, except Android 16 it seems, raising the minimum installable target sdk so eventually updates will be needed to run on new devices.
The second app is often the Aurora Store app store app, from within the F-Droid app, which then lets you install Google Play apps without having to have a Google Account:
With these two apps installed first, on any Android device, whether locked or not, without any need for any computer or any other device, without having to type-in any Google Account details, you can then do pretty much whatever you require on the device, including installing bank apps, Amazon, Amazon Music, Audible, Prime Video, etc.
Sadly, iOS has no alternatives like this. Apple proudly reports terminating 128,961,839 customer accounts in 2024 (yes, Apple has terminated 129 million customer accounts in just one year), and they do NOT allow using an iOS device without an Apple customer account:
It's such bullshit. Having been fed up with Google over the last year, since releasing for Android, I'm slowly moving away from them and prioritizing iOS. Haven't had to deal with nearly as much bullshit with them.
Please note that you can let people download the .apk from your website (for now!), and although the end user will have to bypass 2-3 scare screens, it's not possible at all on Apple products. (Even after the EU mandated Apple to make this possible and then fined them a few billions for not doing it, Apple still hasn't done it)
At this point, I've also basically abandoned my Google Play apps. I simply cannot afford the time to keep them up to date for no good purpose.
And it's absurd. They were a perfectly sustainable “business” with a single unobtrusive banner ad (no tracking, no permissions aside from internet), that was more than enough to cover server costs indefinitely, for around a million monthly active users. The ad free versions costed $2 but was actually less financially attractive to me (I only created it to give the 1% of users that said they wanted it the option).
They are replaced by apps with full screen ads, trackers and subscriptions.
SECUSO is a shining beacon in the Android app space! Thank you for all your work.
One wishes smartphones was less of a moving target so that the maintenance burden was reasonable. Recompiling all your Windows software every year would seem beyond silly, but here we are.
As of right now, if you want to be able to run new Windows software without risk of being quarantined by Microsoft Defender, it needs to be signed with a Microsoft-issued certificate.
Requiring periodic updates is not out of the question for Windows apps in the future perhaps with an exception enabled via group policy that's only available for Enterprise versions of Windows, and must be set for each and every individual .exe and .dll.
Good. Developers should follow suit. Each day I blame myself for having got into what the industry has become: a digital sisyphean nightmare. Either update or die.
not a developer here, but doesn't somebody make a service that can just "update" the app every day by moving functions around in the make file or something? Pointless rules deserve pointless solutions.
I don't particularly agree with Epic's victory in the Google/Epic case, but the one thing I hope it accomplishes is to convince those in charge of the Play Store that it's finally time to have developer-friendly policies (otherwise someone else will). Play Store policies constantly virtue signal about security and privacy while continually making it harder for developers to release high quality apps.
Same thing happened to all my apps. 10 years of games removed due to policy updates that I just couldnt rebuild quickly. Ended up hosting the APKs on my site. Self contained, no third party services but still failed checks.
Google has become more structured and strict in their mobile dev program but still much easier go cope with than Apple when exception handling is required. Apple fails in many fronts in these matters.
These apps are great. They do exactly what it says on the tin. Pity to hear this, now people will have an even harder time getting nonshit bloatware from the Play store.
That's a lot of noise for not much. Yes, the Play store makes you stay up to date with recent Android versions. When I see whining about updating "privacy friendly flashlight", it's literally a single number to change in your build.gradle considering how low feature it is. It's a 5 minute job. 15 if you want to open up android studio and upgrade gradle.
If I can't trust you to do that, why can I trust you with my privacy? Are you using libs that still write in the shared data directory? Do you maintain your http clients up to date to not be fucked by SSL downgrades?
You can even upgrade two versions above (API 36), and you'll be fine for two years.
There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
And yes, if you don't want to do that, put it on fdroid. Host the APK on your website instead of making people go through the most privacy invading service to provide your privacy apps.
I didn't find any noise or whining in the post. The text mentions "effort to keep the apps updated" which is more than just updating the API number. You are frequently requested to adapt the app, the signing process, fill in the ever increasing compliance data. Every request for change is accompanied with a threat.
My app had no privacy concerns, didn't collect any data or even require internet access.
I was still expected to jump through all kinds of hoops every few months. Even after I gave up and my app was delisted I still get regular requests for new hoops they came up with with more threats that they would delist (even more?).
And yes, the app was moved to F-Droid which makes it invisible for just about 100% of Android users. I still think these kinds of posts serve as a good deterrent so others don't invest the effort in the Google Play store. The store is meant for corporations. If you are enthusiast or a non-profit considering the app a one-time investment, it will pester you and wear you down.
> There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
The massive API changes are why it's not just bumping a number. That's the exact core problem
The massive API changes that break apps are tangential to the Play Store.
It's Android itself that's crap, and Fdroid or any other alternative app store isn't going to help on this particular issue. Note that iOS has the same issue.
They have more than 30 apps, not just a flashlight. It's mentioned right there in the post.
Do you really thing these people are complete idiots who can't increment a number? Obviously it's more than that. And the "wHy CaN I TrUSt yOu wITh mY prIvACy" shade throwing is just outright bizarre.
Updates get "tested", but unless it just immediately crashes on launch, this is not a reason for rejection.
Screenshot updates are not necessary (just recommend to improve your rankings), and eventually answering some questions like "do you handle personal information in the app?". There's a few edge cases where you need to prove that you're using a specific permission for good reason.
From a cursory glance, their apps seem to be of the kind that don't need continuous updates and can be considered complete. Self-contained, offline software that serves a specific purpose: https://search.f-droid.org/?q=SECUSO&lang=en
Unfortunately, Google no longer recognizes this as a valid development strategy. If you want to publish on Google Play, you need to continuously release updates targeting an SDK released within the past year[0]. If you don't, they will send you constant warnings about how your app is violating their policies, they might derank your app, and eventually they'll stop making your app available to new users.
Updating the SDK is not that simple and it often introduces new bugs if you don't read through the full changelog and test thoroughly. I have 3 apps and it already feels like I spend too much time each year updating SDK, I can't imagine updating 30.
They talk about how this somehow improves security and enhances user experience, meanwhile this policy worsens user experience by pushing people towards ad-filled apps that have the resources and courage to release needless updates, and they still publish spyware on their store.
[0] https://developer.android.com/google/play/requirements/targe...
I've attempted to make this point to proponents of the walled gardens as a real benefit they are losing. There are app developers that just want to make useful stuff and share it. But Play (and the App Store) are completely designed around developers that are trying to make a living there (because that's how Google/Apple make money off the store). As such, the stores are quite hostile to community built software that changes rarely. This is a real loss, as I think that software is often the best available for a given purpose due to simplicity, privacy, and longevity.
So glad I have F-Droid!
I've had some thoughts in a similar vein, but I was thinking from a privacy perspective. The Google and Apple arguments for the walled gardens basically boil down to "You can't trust other stores to protect your privacy and security", but the obvious counter-argument to that is that other stores may actually be able to focus more on privacy and security than the walled gardens do.
Apple and Google inevitably have limited privacy protections, because they'd probably run off Meta and a bunch of other really popular / in-demand apps and cut into their own bottom-line if they really cracked down. In contrast, a third party store may be more free to only host apps that are more privacy-oriented or have been security audited, etc.
2 replies →
Great point, and also: the walled garden operators don't make any money off of free apps, so they don't prioritize supporting creators of free apps. The result is that it becomes unsustainable for most developers to keep a free app on the store.
The incentive structure of walled garden app stores encourages the proliferation of paid apps for everything, including things like an instrument tuner or a notepad app that'd be free in a non-walled garden environment.
Interesting how Web API’s and mobile have gone in different directions. If a web browser breaks compatibility too much then it’s a broken browser.
2 replies →
> "Additionally, the app prevents devices from taking screenshots."
Why do the "security" apps ALWAYS have to have this anti-feature? It's especially annoying when employed by the banking apps.
Famously, Schwab had some issues where it didn't properly keep track of orders during highest loads (people ending up selling more shares than they had even in IRA accounts), yet conveniently they prevent users from taking screenshots of their app, so you wouldn't be able to prove that you did cancel or replace the order and did receive the cancel confirmation, before it executed anyways. Of course, if it's an IRA account, selling more shares than you own, is clearly Schwab's bug, but not being able to keep these things locally, is one of the biggest anti-features of modern apps.
> Why do the "security" apps ALWAYS have to have this anti-feature?
Every pen test I’ve seen for mobile apps has always had this as an item, even when it’s completely unjustified for the type of app. It’s on their checklist and they will always flag it to show they are doing their job. If you don’t have anybody in the team who is willing and able to say no to a pen tester on a security matter, this kind of thing will happen.
4 replies →
At a previous employer of mine, it was common to share dev accounts for certain things. These were not security sensitive things. They were there purely for dev purposes and these were things like anayltics tools and stuff that the software being built had to integrate with, so they were basically development sandboxes.
Many of these tools had MFA enabled and so it was common to share MFA codes on Slack because the MFA code was sent to an email address that only one person had access to.
One lunch and learn a group of developers shared how they solved this problem by having the MFA codes pushed to a device that was effectively an on-prem server / dev box that they installed custom built software on to take a screenshot of the MFA code and broadcast it on the relevant Slack channel.
The main point of the lunch and learn, however, wasn't so much to share the tool that they had built, but to talk about how they got around the Mac OS security protections that are there to prevent this sort of thing.
My first thought was "we've just written malware."
I'm specifically responding to this sentence of yours:
> It's especially annoying when employed by the banking apps.
After my experience with that MFA code sniffer ... I know exactly why banking apps and other privacy/security-centred apps prevent taking screenshots :)
10 replies →
I've gone off Schwab big time over the past year.
a) I cancelled my "intelligent advisor" accounts (which was a pain to do by itself) and had the money xferred back into regular IRA accounts. After this was complete, I was no longer able to see any trade history for the past 12 years of those Intelligent Advisor accounts, *even though they were ostensibly backed by regular Schwab IRAs*, and my historical "wealth" tracking in Schwab made it look like I'd simply never had the $NNN^n that was in those accounts for that period of time, or in other words as if I'd added $NNN^n to my accounts on the day of the transfer. Definitely some hackery there. I had one Schwab rep who acknowledged this as a (rather severe) problem, but the other 3 I spoke to did not even understand why it was an issue.
b) For an example of their approach to data in general, take a look at their historical chart for the WEED ETF around the time of the reverse split in 2023, and compare it to how WEED themselves chart it, and how Fidelity charts it. Schwab's presentation of the price history isn't justifiable, and essentially omits information. (https://www.schwab.com/research/etfs/quotes/summary/weed, https://www.roundhillinvestments.com/etf/weed/, https://digital.fidelity.com/prgw/digital/research/quote/das...). Their support brushed this off.
That's a very shallow protection. Even if one has no other camera (phone, table, a real camera) there are always friends and relatives that can help and take a picture of the screen. Furthermore a picture of the screen and the phone around it has a more real feel than a screenshot that could be photoshopped.
1 reply →
Yeah, SDK updates are a pain. I wrote ChromaDoze in 2010 so I've gone through several. Recently, the most annoying changes were:
- Foreground services used to require a persistent notification, now they're not allowed to have a notification unless you prompt the user. So I added a button to beg for POST_NOTIFICATIONS permission, but now permission can be granted after the service starts, so I had to build some magic to make the service refresh its own notification.
- Gesture navigation steals user input when swiping on the left/right edges of the screen, so I had to build some magic to automatically make my UI narrower when gesture navigation is enabled. Drawing apps can't really use setSystemGestureExclusionRects() because it's limited to 200dp.
- By default, apps now render edge-to-edge vertically, behind the semi-transparent status bar and bottom navigation buttons, so I had to build some magic to avoid those areas.
Now that gesture navigation is the default, many developers aren't testing with 3-button navigation, so I've noticed apps where I can't interact with the bottom because it collides with my navigation buttons.
> - Gesture navigation steals user input when swiping on the left/right edges of the screen,
Well I've seen even 1B+ dl apps failing to handle that (on a Google Pixel), so at this point I'm putting the blame on Google. I've switched back to three button navigation. Though even some trivial OS gestures like screen unlock fail reliably on my Pixel 6a. (As in, I do the gesture, it fails to register the gesture, i try to make the gesture "with more conviction" through the whole screen and it still fails, and after few minutes it ends up okay somehow)
2 replies →
Just wanted to give my thanks for ChromaDoze. I use it on flights all the time to help drown out noise. A brilliant open source app.
I also share this resentment. It became very hard to have a niche app for a family or a small circle. Not like it was easy before, but amount of time one needs to invest to keep it up to date with requirements is not sustainable. Web apps are also a hard thing once you consider hosting and storage expenses.
If you have an app for a small restricted audience, it shouldn't need to meet Play Store requirements, just basic Android ones.
I think both of you and TFA misunderstand what the targetSdkVersion is.
If your app barely uses any permissions (like TFA's apps), you just need to update the targetSdkVersion in the manifest once per year and push the update. That's it. You're not updating SDKs or compiling against a newer SDK or anything.
4 replies →
I find this kind of posting deeply ironic, since HN and ArsTechnica has been ripping Android a new one before this policy came into effect for allowing apps to exploit old APIs for stealing data, triggering popups, spamming notifications and many more changes that have been done from there. Many praises were sung to superiority of iOS and their demand to keep up to date with new policies and even new design.
And now we hear complaining again over things like... (a few posts lower)... having to implement permission dialog to show notifiactions? Right :D
The reality of the situation is that without required SDK changes, every single app - from your banking app to every game - would STILL demand access to all your files, all your documents, all your photos (and their locations) before they run. And then proceeded to spam you with notifications from background trying to sell you crypto.
Fixing those things unfortunately means that also the opensource developers need to move their behinds and implement APIs in a way that respect users more.
So just don't let developers push updates targeting old SDKs? Show a scary permission dialog on every app launch for dangerous permissions? Delist only the apps that actually use or at least register those permissions?
There are many possible solutions and none of them are "you have to recompile once per year or we ban you".
2 replies →
Sites like HN are different people with different opinions posting different views, so of course some of that will conflict. I don't get why this staggeringly obvious fact needs to be explained over and over again...
And beyond those things there are often performance / battery optimization related things as part of the update too. Just because an app claims it respects your privacy, it doesn't mean that it is a well behaved app.
Most other android app stores enforce a high target sdk. Fdroid is the only one I know that doesn't and allows apps as far back as Android supports. Android has been yearly, except Android 16 it seems, raising the minimum installable target sdk so eventually updates will be needed to run on new devices.
Not exactly constantly update, in past 4 years it was only 2 or 3 required updates to rebuild with latest SDK.
I hope this push from Google (and also from Apple) forces us, the developers, to create and most important USE the alternatives.
The F-Droid app store app is usually already the first app I ever install on any Android device:
https://f-droid.org/
The second app is often the Aurora Store app store app, from within the F-Droid app, which then lets you install Google Play apps without having to have a Google Account:
https://f-droid.org/packages/com.aurora.store/
With these two apps installed first, on any Android device, whether locked or not, without any need for any computer or any other device, without having to type-in any Google Account details, you can then do pretty much whatever you require on the device, including installing bank apps, Amazon, Amazon Music, Audible, Prime Video, etc.
Sadly, iOS has no alternatives like this. Apple proudly reports terminating 128,961,839 customer accounts in 2024 (yes, Apple has terminated 129 million customer accounts in just one year), and they do NOT allow using an iOS device without an Apple customer account:
https://www.apple.com/legal/more-resources/docs/2024-App-Sto...
10 replies →
It's such bullshit. Having been fed up with Google over the last year, since releasing for Android, I'm slowly moving away from them and prioritizing iOS. Haven't had to deal with nearly as much bullshit with them.
Please note that you can let people download the .apk from your website (for now!), and although the end user will have to bypass 2-3 scare screens, it's not possible at all on Apple products. (Even after the EU mandated Apple to make this possible and then fined them a few billions for not doing it, Apple still hasn't done it)
Sorry to inform you that Apple has the same bs:
https://appleinsider.com/articles/25/07/15/developer-angry-t...
At this point, I've also basically abandoned my Google Play apps. I simply cannot afford the time to keep them up to date for no good purpose.
And it's absurd. They were a perfectly sustainable “business” with a single unobtrusive banner ad (no tracking, no permissions aside from internet), that was more than enough to cover server costs indefinitely, for around a million monthly active users. The ad free versions costed $2 but was actually less financially attractive to me (I only created it to give the 1% of users that said they wanted it the option).
They are replaced by apps with full screen ads, trackers and subscriptions.
SECUSO is a shining beacon in the Android app space! Thank you for all your work.
One wishes smartphones was less of a moving target so that the maintenance burden was reasonable. Recompiling all your Windows software every year would seem beyond silly, but here we are.
As of right now, if you want to be able to run new Windows software without risk of being quarantined by Microsoft Defender, it needs to be signed with a Microsoft-issued certificate.
Requiring periodic updates is not out of the question for Windows apps in the future perhaps with an exception enabled via group policy that's only available for Enterprise versions of Windows, and must be set for each and every individual .exe and .dll.
For context, something similar happened to an iOS game: https://appleinsider.com/articles/25/07/15/developer-angry-t...
Good. Developers should follow suit. Each day I blame myself for having got into what the industry has become: a digital sisyphean nightmare. Either update or die.
Agreed, and iOS devs should follow suit too. If the store you're distributing with isn't the best option for you, you should find a better partner.
not a developer here, but doesn't somebody make a service that can just "update" the app every day by moving functions around in the make file or something? Pointless rules deserve pointless solutions.
Each new Android SDK has breaking changes to the API. All of them break compatibility.
No issue is that with new Android versions, it wont work.
I don't particularly agree with Epic's victory in the Google/Epic case, but the one thing I hope it accomplishes is to convince those in charge of the Play Store that it's finally time to have developer-friendly policies (otherwise someone else will). Play Store policies constantly virtue signal about security and privacy while continually making it harder for developers to release high quality apps.
Same thing happened to all my apps. 10 years of games removed due to policy updates that I just couldnt rebuild quickly. Ended up hosting the APKs on my site. Self contained, no third party services but still failed checks.
What is the partial derivative symbol doing in their email address (last line of the page)?
It's to fool primitive scrapers looking for e-mail addresses with the @ symbol. It's handled like that on the entire KIT website.
This can't be it because on mouseover I get the mailto: link with the @ symbol in it.
Google has become more structured and strict in their mobile dev program but still much easier go cope with than Apple when exception handling is required. Apple fails in many fronts in these matters.
These apps are great. They do exactly what it says on the tin. Pity to hear this, now people will have an even harder time getting nonshit bloatware from the Play store.
I get apps only from F-Droid, so this is fine.
Meanwhile every ad my elderly family members get while playing some dipshit game on android is a literal scam and has been for ten fucking years...
"Malware detected" yeah I know where, too.
That's a lot of noise for not much. Yes, the Play store makes you stay up to date with recent Android versions. When I see whining about updating "privacy friendly flashlight", it's literally a single number to change in your build.gradle considering how low feature it is. It's a 5 minute job. 15 if you want to open up android studio and upgrade gradle.
If I can't trust you to do that, why can I trust you with my privacy? Are you using libs that still write in the shared data directory? Do you maintain your http clients up to date to not be fucked by SSL downgrades?
You can even upgrade two versions above (API 36), and you'll be fine for two years.
There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
And yes, if you don't want to do that, put it on fdroid. Host the APK on your website instead of making people go through the most privacy invading service to provide your privacy apps.
I didn't find any noise or whining in the post. The text mentions "effort to keep the apps updated" which is more than just updating the API number. You are frequently requested to adapt the app, the signing process, fill in the ever increasing compliance data. Every request for change is accompanied with a threat.
My app had no privacy concerns, didn't collect any data or even require internet access. I was still expected to jump through all kinds of hoops every few months. Even after I gave up and my app was delisted I still get regular requests for new hoops they came up with with more threats that they would delist (even more?).
And yes, the app was moved to F-Droid which makes it invisible for just about 100% of Android users. I still think these kinds of posts serve as a good deterrent so others don't invest the effort in the Google Play store. The store is meant for corporations. If you are enthusiast or a non-profit considering the app a one-time investment, it will pester you and wear you down.
> There's plenty to complain about with Google and Android. Massive API changes. But the Play store saying "please ensure you at least checked what happens when we draw the app edge to edge because Android 15 forces it" is not one.
The massive API changes are why it's not just bumping a number. That's the exact core problem
The massive API changes that break apps are tangential to the Play Store.
It's Android itself that's crap, and Fdroid or any other alternative app store isn't going to help on this particular issue. Note that iOS has the same issue.
They have more than 30 apps, not just a flashlight. It's mentioned right there in the post.
Do you really thing these people are complete idiots who can't increment a number? Obviously it's more than that. And the "wHy CaN I TrUSt yOu wITh mY prIvACy" shade throwing is just outright bizarre.
Aren‘t updates reevaluated by Google.
So it‘s not just a simple rebuild and an upload but Google wants certain screenshots of the app and all kinds of additional information
Updates get "tested", but unless it just immediately crashes on launch, this is not a reason for rejection.
Screenshot updates are not necessary (just recommend to improve your rankings), and eventually answering some questions like "do you handle personal information in the app?". There's a few edge cases where you need to prove that you're using a specific permission for good reason.
Too bad there's no downvoting on HN.
There is, it's unlocked with enough karma
There is, for users with at least 501 karma[1].
[1] https://github.com/minimaxir/hacker-news-undocumented/blob/m...
1 reply →