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.
So glad I have F-Droid!
cnst · 1h ago
> "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.
p1mrx · 52m ago
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.
zihotki · 1h ago
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.
nolist_policy · 1h ago
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.
a2128 · 44m ago
It's not that simple. If it were that simple Android Studio wouldn't show you a big red error when you do that and they wouldn't have built an entire assistant for the purpose of incrementing a number[0]. The reason is that bumping the targetSdkVersion changes various behavior, sometimes in a breaking manner. A good recent example is that 34 -> 35 will force edgeToEdge rendering on all activities unless you opt-out per-window (and 35 -> 36 removes the opt-out). So simply doing what you said would probably lead to UI elements appearing behind the nav/status bars and the app being unusable (on API 35+ devices, from my understanding).
You do need a newer SDK to update the target-sdk-version though. And you may find that libraries you used are not compatible, unless you update them, and updating them may break things. Maybe for a minimal app in pure java or kotlin this won't be a problem.
There was an open-source app that hasn't been updated in a few years that was delisted from the store. I decided to try my hand at recompiling to target latest required sdk "target" or whatever. It used Xamarin / C# and some additional libraries. It does not talk to the internet, it's just a minimal remote-control and data-logger for a bluetooth multimeter. If you can find a copy of the last APK published and sideload it, it works. But if you try to update the SDK so you can target the required SDK version for the Play Store, compile fails, misc cryptic errors due to libraries. Updating libraries was tricky for me because while I'm quite familiar with C, C++, Python, Go (etc), I'm not at all familiar with Android, Java, Kotlin, nor C#, visual-studio, etc. After a few days of struggle I managed to update libraries and fix the build, but the app's layout was totally broken, only one button appears (and again I'm not familiar with any of this stuff).
This app really didn't need any updates. It's a < 20MB app to control a local device, and it still works. At least you can still side-load it. Sheesh.
nolist_policy · 1h ago
> You do need a newer SDK to update the target-sdk-version though.
No you don't.
You probably should just use an older version of Android Studio for your case which supports the original compileSdkVersion from the original gradle build. Then update the targetSdkVersion in the manifest and that's it.
owebmaster · 2h ago
I hope this push from Google (and also from Apple) forces us, the developers, to create and most important USE the alternatives.
cnst · 1h ago
The F-Droid app store app is usually already the first app I ever install on any Android device:
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:
How do you even get to the point of installing F-Droid without first setting up Android, which, in my experience, requires a valid Google login.
When I set up my Android device, there wasn't an option to set it up without a Google Account.
cnst · 20m ago
There's always a "later" or equivalent button in all of these setups, sometimes it does have a few prompts.
I personally have iPhone, Google Pixel, OnePlus, Motorola and Samsung devices, without any accounts on them. The iPhones are very limited without an account, obviously, but I never feel that way on Android.
All that I did to set them up, is click on the screen a few times, no extra tools or anything. Then just go into the browser, and follow the instructions for F-Droid installation; which can be done entirely on the phone, without a computer or any other phone, or any username/password.
Semaphor · 52m ago
That's not normal, that will probably be the vendor skin you use enforcing that. Maybe samsung, as they tend to try and be apple at home.
throwaway743 · 29m ago
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.
xorcist · 2h ago
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.
brnt · 2h ago
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.
ohdeargodno · 1h ago
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.
jmiskovic · 1h ago
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.
philipwhiuk · 47m ago
> 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
croes · 1h ago
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
ohdeargodno · 1h ago
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.
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...
So glad I have F-Droid!
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.
- 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.
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.
[0] https://developer.android.com/build/sdk-upgrade-assistant
There was an open-source app that hasn't been updated in a few years that was delisted from the store. I decided to try my hand at recompiling to target latest required sdk "target" or whatever. It used Xamarin / C# and some additional libraries. It does not talk to the internet, it's just a minimal remote-control and data-logger for a bluetooth multimeter. If you can find a copy of the last APK published and sideload it, it works. But if you try to update the SDK so you can target the required SDK version for the Play Store, compile fails, misc cryptic errors due to libraries. Updating libraries was tricky for me because while I'm quite familiar with C, C++, Python, Go (etc), I'm not at all familiar with Android, Java, Kotlin, nor C#, visual-studio, etc. After a few days of struggle I managed to update libraries and fix the build, but the app's layout was totally broken, only one button appears (and again I'm not familiar with any of this stuff).
This app really didn't need any updates. It's a < 20MB app to control a local device, and it still works. At least you can still side-load it. Sheesh.
No you don't.
You probably should just use an older version of Android Studio for your case which supports the original compileSdkVersion from the original gradle build. Then update the targetSdkVersion in the manifest and that's it.
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...
When I set up my Android device, there wasn't an option to set it up without a Google Account.
I personally have iPhone, Google Pixel, OnePlus, Motorola and Samsung devices, without any accounts on them. The iPhones are very limited without an account, obviously, but I never feel that way on Android.
All that I did to set them up, is click on the screen a few times, no extra tools or anything. Then just go into the browser, and follow the instructions for F-Droid installation; which can be done entirely on the phone, without a computer or any other phone, or any username/password.
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.
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.
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.
The massive API changes are why it's not just bumping a number. That's the exact core problem
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
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.