[HN Gopher] Our Farewell from Google Play
___________________________________________________________________
Our Farewell from Google Play
Author : shakna
Score : 213 points
Date : 2025-08-01 09:08 UTC (13 hours ago)
(HTM) web link (secuso.aifb.kit.edu)
(TXT) w3m dump (secuso.aifb.kit.edu)
| a2128 wrote:
| 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...
| owebmaster wrote:
| I hope this push from Google (and also from Apple) forces us,
| the developers, to create and most important USE the
| alternatives.
| cnst wrote:
| 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...
| butshouldyou wrote:
| 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.
| Semaphor wrote:
| 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.
| hadrien01 wrote:
| I have a Samsung phone and I was never forced to use a
| Google account.
| cnst wrote:
| 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.
| immibis wrote:
| Whenever I buy a new Android device I take the
| opportunity to pretend I'm a grandma getting her first
| piece of technology and create a brand new Google
| account, since it's one of the only signup pathways that
| doesn't require some kind of identity verification.
| cnst wrote:
| That's a nice trick to get a fresh Google Account without
| any verifications!
|
| 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.
| swiftcoder wrote:
| > Top 10 guidelines or DPLA provisions cited for removal >
| 1. Guideline 4.0 -- Design: 42,2527
|
| 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 wrote:
| Honestly, thank you for this. I'm going to do this on an
| Amazon Fire Tablet I have lying around.
| zihotki wrote:
| 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 wrote:
| 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.
| ploxiln wrote:
| 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 wrote:
| > 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.
| sltkr wrote:
| While you are _technically_ correct (the best kind of
| correct), official guidance is to use support libraries
| that are at least as new as the targetSdkLevel, so if you
| follow that recommendation you still have to update.
|
| 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 wrote:
| 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).
|
| [0] https://developer.android.com/build/sdk-upgrade-
| assistant
| Zak wrote:
| If you have an app for a small restricted audience, it
| shouldn't need to meet Play Store requirements, just basic
| Android ones.
| cnst wrote:
| > "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.
| pmontra wrote:
| 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.
| cnst wrote:
| A screenshot develops evidence of something happening or
| not happening according to the person who took the
| screenshot.
|
| 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 wrote:
| 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://digit
| al.fidelity.com/prgw/digital/research/quote/das...). Their
| support brushed this off.
| JimDabell wrote:
| > 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.
| kstrauser wrote:
| Agreed.
|
| 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 wrote:
| I simply delete and rate 1* any app that doesn't work,
| including Schwab.
|
| 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 180deg 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 wrote:
| This is exactly how I recognise bad "pentest" firms and
| tell all my friends and clients the same. If the pentest
| contains report any mention of [screenshot, obfuscation,
| root detection, attestation] it's bullshit and you should
| demand your money back (you won't get it, but still, you
| should demand it) and tell everyone in your circle to not
| give another cent to them.
| gspencley wrote:
| 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 :)
| liendolucas wrote:
| Yes, but that can be simply solved by the banking app to
| re-ask for the PIN instead of directly declining to take
| the screenshot.
|
| 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 wrote:
| Some do that, and it's super annoying. I take a
| screenshot, and then silently my login doesn't work, with
| a weird error returned instead. Get another PIN, type it
| in, take a screenshot before submit, again get a
| nondescript error that makes no sense.
|
| 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 wrote:
| I fail to see how your conclusion follows from the premise.
|
| 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 wrote:
| >why should the camera function of any app prevent that
| again?
|
| 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 wrote:
| > Another app on the device screen recording that view
| may not be intentional by the user.
|
| 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 wrote:
| Not more then for any other app. Android design is such
| that it intentionally trains users to accept everything.
| cnst wrote:
| Surely you're talking about Apple's design, no?
|
| 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 wrote:
| Yes, more than anything else:
| https://github.com/cvzi/ScreenshotTile?tab=readme-ov-
| file#te... Depending on method and version of Android,
| you have to jump through ridiculous steps to allow
| screenshots.
| rpdillon wrote:
| 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!
| protimewaster wrote:
| 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.
| immibis wrote:
| Arguments in this day and age are soldiers[1], at least
| when they come from powerful people: (if you're a
| corporation or a government) they are things you send to
| fight for you. You don't have to actually believe them, and
| the most effective ones are often not ones that are true.
|
| [1] https://www.lesswrong.com/w/arguments-as-soldiers
| skybrian wrote:
| 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.
| dwaite wrote:
| Compatibility is broken constantly on the web, but it is
| forward compatibility. This is why most browsers now auto-
| update to newer versions. Websites then require new
| features which will result in older browsers being non-
| functional.
|
| 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 wrote:
| True, complicated websites need to be tested. But if a
| web site serves simple web pages then it generally
| doesn't have a maintenance burden. (Though, link rot
| happens to everyone.)
| Centigonal wrote:
| 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.
| p1mrx wrote:
| 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.
| phh wrote:
| > - 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)
| cyberax wrote:
| > I've switched back to three button navigation.
|
| 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 wrote:
| > I've switched back to three button navigation.
|
| 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.
| throwaway743 wrote:
| 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.
| rs186 wrote:
| Sorry to inform you that Apple has the same bs:
|
| https://appleinsider.com/articles/25/07/15/developer-
| angry-t...
| dostick wrote:
| Not exactly constantly update, in past 4 years it was only 2 or
| 3 required updates to rebuild with latest SDK.
| izacus wrote:
| 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.
| charcircuit wrote:
| 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.
| franga2000 wrote:
| 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".
| izacus wrote:
| Ehm, that's EXACTLY what happens now.
|
| 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 wrote:
| What part of what I said suggested "old sdk targeting
| apps don't appear to users (unless the user has already
| installed that app before)" would be fine?
|
| If the app works and doesn't do anything bad, there's no
| reason to delist it.
| mossTechnician wrote:
| One of the best image editors I've ever used, PicSay Pro, fits
| in the "complete" category. It's surprisingly powerful for
| splicing together images and adding text, giving you rotation
| and perspective controls.
|
| It's been feature complete since the early 2010s[0].
|
| I haven't found a comparable image editor since then. All the
| new ones seem to push AI and internet connectivity, and only
| have a fraction of the power user features that are buried in
| PicSay.
|
| [0]: https://www.wired.com/2011/11/picsay-pro-app/
| brnt wrote:
| 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.
| xorcist wrote:
| 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.
| bitwize wrote:
| 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.
| ohdeargodno wrote:
| 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.
| croes wrote:
| 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 wrote:
| 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.
| jmiskovic wrote:
| 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 wrote:
| > 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
| naeq wrote:
| Too bad there's no downvoting on HN.
| mananaysiempre wrote:
| There is, for users with at least 501 karma[1].
|
| [1] https://github.com/minimaxir/hacker-news-
| undocumented/blob/m...
| naeq wrote:
| Good to know, thanks!
| alex1138 wrote:
| There is, it's unlocked with enough karma
| amelius wrote:
| What is the partial derivative symbol doing in their email
| address (last line of the page)?
| Aulig wrote:
| It's to fool primitive scrapers looking for e-mail addresses
| with the @ symbol. It's handled like that on the entire KIT
| website.
| amelius wrote:
| This can't be it because on mouseover I get the mailto: link
| with the @ symbol in it.
| dotdev wrote:
| 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.
| rs186 wrote:
| For context, something similar happened to an iOS game:
| https://appleinsider.com/articles/25/07/15/developer-angry-t...
| ncruces wrote:
| 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.
| hollowonepl wrote:
| 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.
| Animats wrote:
| I get apps only from F-Droid, so this is fine.
| liendolucas wrote:
| 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.
| abakker wrote:
| 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.
| watwut wrote:
| No issue is that with new Android versions, it wont work.
| suddenexample wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-01 23:01 UTC)