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.
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.
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.
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.
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
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.
[1] https://github.com/minimaxir/hacker-news-undocumented/blob/m...
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.
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.
"Malware detected" yeah I know where, too.
a2128•14h ago
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...
owebmaster•13h ago
cnst•13h ago
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...
butshouldyou•12h ago
When I set up my Android device, there wasn't an option to set it up without a Google Account.
Semaphor•12h ago
hadrien01•9h ago
cnst•11h ago
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.
immibis•11h ago
cnst•10h ago
But why would you need so many Google accounts? I think at one point it may simply become cumbersome to keep track of all the accounts, so, using an account-less Aurora Store seems like a very easy pathway to take.
I honestly never feel disadvantaged in any way by not having a Google Account on my Android. Aurora Store works, Google Maps works, banking and streaming works, everything just works.
immibis•2h ago
cnst•32m ago
On my main device, I'd use a regular Google Account. But if I'm getting a test device, or a device I simply play around with, it doesn't have to have a Google Account, and yet it can still have all the apps I'd ever want.
Unlike with iOS, where you're severely limited in trying out a device without having an Apple Account. Yet somehow it's Apple that's deemed to respect people's privacy, go figure.
swiftcoder•9h ago
Does that line item mean that Apple is rejecting the largest body of apps for not meeting the design guidelines? Man... if I had a penny for every app still on the App Store that blatantly disregards the human interface guidelines...
willhslade•4h ago
zihotki•13h ago
nolist_policy•12h ago
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.
ploxiln•12h ago
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•12h ago
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.
sltkr•11h ago
Also, I try to at least do the bare minimum level of testing the app still works after rebuilding by launching the app in the emulator once (I don't usually have a phone that runs the newest API level), which means downloading at least a new emulator image.
In practice it's just easier to update the entire platform.
a2128•12h ago
[0] https://developer.android.com/build/sdk-upgrade-assistant
Zak•9h ago
cnst•12h ago
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.
pmontra•10h ago
cnst•10h ago
If you start claiming that it can be photoshopped, well, what prevents anyone from photoshopping a real camera shot? Or photoshopping a screenshot, and then taking a "real" shot with a camera? With AI, you can now even do this with video, too.
For practical purposes, your suggestion is simply unrealistic. It's unrealistic to be using a second phone to be taking random confirmations from your main phone, and it's even more unrealistic if you're doing trading where every second counts, and where the whole reason that Schwab cannot execute properly, is because orders are placed and cancelled than once. It's even yet more unrealistic because of focus and angle issues, and reduced precision, and increased file size etc.
BTW, I have personally encountered this consistency bug at Schwab Brokerage. I wasn't even using Schwab's app, precisely because it doesn't let you take screenshots. In my case, the loss was not major, and not worth pursuing.
But other people reported that their IRA accounts sold shares short as a result of this consistency issue, which is kind of a problem for everybody when you cannot buy it back if it has 10x'ed since the sale like GME once had, and cannot even add any more money even if you have it, because it's a tax-advantaged account with limits on how much you can add each year.
smallerfish•10h ago
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.
JimDabell•10h ago
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.
kstrauser•8h ago
I'm the person who enjoys saying no to this kind of thing. Also, we will not disable copy and paste for password fields, and we will not make our users rotate their passwords every 11 days ("because we align with NIST guidelines which say not to do that").
cnst•7h ago
Schwab's mobile website is actually decent, and, basically, works better than their app in every way.
I'm honestly disappointed Android doesn't do something about these broken apps that don't let me keep records of my own stuff.
It should not be possible for an app to prevent screenshot use 100% of the time.
There should also be a 180° on the checklists to flag any app that uses disable-screenshot 100% of the time, similar to how we went from requiring people to change passwords every 14 days, to removing the mandatory-password-change policy in its entirety.
franga2000•6h ago
immibis•2h ago
gspencley•10h ago
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 :)
liendolucas•7h ago
If it asks me again my PIN when I'm about to hit "transfer" when sending money, there should be no problem in doing the same for the screenshot.
Instead at least my banking app forces me to navigate through an unfamiliar menu and donwload a PDF. A waste of time compared to taking a screenshot.
cnst•7h ago
Don't they star the PIN in any case?
Why exactly is me taking a screenshot of my signup process for my records suddenly a disqualifier for signing up?
If all these companies never lied to us about the terms of the deals we're signing up for, needing proof of what actually happened, we'd never be taking these screenshots.
Honestly, this whole "security" theatre ought to be investigated by the consumer protection agencies, and any app that prevents screenshots being taken, or gives these nondescript errors when someone takes it and is subsequently unable to sign-in, should be fined for their anti-consumer behaviours.
cnst•7h ago
Banking apps in the US don't even show any PINs for 2FA, so, why exactly is Schwab doing that again?
BTW, Google Wallet does let you take screenshots of all the views except for just one or two views where you enter card number, billing and card security code. Honestly, even that is an overreach; it's not like I can't use the camera to take a photo of my credit card with CVV in view, so, why should the camera function of any app prevent that again? Google never blocks screenshots of any transactions, last-4 of any card, or any other screens. If they ever did, I'd be far less happy with them, and would go out of my way to find an alternative contactless provider. Wells Fargo used to provide contactless on Android in their app for their own cards, but, probably thanks to Apple, this feature was removed for feature parity with iOS.
charcircuit•6h ago
Because you taking a photo of it with a physical camera is intentional. Another app on the device screen recording that view may not be intentional by the user.
yjftsjthsd-h•6h ago
Given how many permission prompts you have to go through to let any app see your screen, I feel to see how it would be unintentional.
watwut•4h ago
cnst•4h ago
With Android, I routinely prohibit random app permissions from many apps, and everything still works just fine.
Does Apple even let you have as fine of a control of permissions as you can have on Android?
yjftsjthsd-h•4h ago
immibis•2h ago
yjftsjthsd-h•39m ago
rpdillon•12h ago
So glad I have F-Droid!
protimewaster•11h ago
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.
immibis•11h ago
[1] https://www.lesswrong.com/w/arguments-as-soldiers
skybrian•9h ago
dwaite•9h ago
Backward incompatible changes happen - they are more difficult due to lack of communication with/pressure on the sites they will break, and coordination of strategy with other browser vendors. This can actually be quite frustrating, as each browser has their own 1-3 month cadence for new releases and it is difficult to track whether a breaking change is going to land on any given browser soon enough to coordinate a new version of a site.
skybrian•8h ago
Centigonal•5h ago
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.
p1mrx•12h ago
- 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.
phh•10h ago
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)
cyberax•9h ago
Don't worry. Google broke it as well with shitty "edge-to-edge" nonsense to make the apps more "engaging" by forcing them to deal with the disappearing bottom bar. By default.
breakingcups•8h ago
I've been using it since forever, but recently noticed that the latest update broke the back button in certain scenarios I can't figure out yet.
edent•3h ago
throwaway743•11h ago
rs186•10h ago
https://appleinsider.com/articles/25/07/15/developer-angry-t...
immibis•2h ago
dostick•9h ago
izacus•7h ago
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.
charcircuit•7h ago
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.
franga2000•6h ago
There are many possible solutions and none of them are "you have to recompile once per year or we ban you".
izacus•6h ago
Noone is being banned because of this. You can't publish an update if it targets old Sdk and old sdk targeting apps don't appear to users (unless the user has already installed that app before).
That's it. Google is directly following your recommendation. Developers have usually more than a full year to comply (e.g. Android 16 has just released, developers will have to target Android 15 at the end of August. Android 15 beta was released around march 2024 giving developers ability to prepare and test).
franga2000•6h ago
If the app works and doesn't do anything bad, there's no reason to delist it.
arp242•2h ago