Google’s play store approval process really is a nightmare. Apple’s reviewers might be slow and not always the most competent, but at least they’re real humans you can talk to and reason with. Google as usual is just an automated process that often gives you little to no actionable feedback.
It's been a couple years since I did mobile dev, but in my experience you don't get to reason much with Apple's reviewers either, but you can change something minor, re-submit, and hope you get a different, better reviewer.
We currently have an app store issue with one of the 8 apps that we provide (same codebase, mostly same Features, different brands etc).
On one of them, we got a very picky reviewer that doesn't like our Account Deletion feature.
This & the other apps had it live for months, the others are still fine, just this one app now can't get updates. And we simply can't make it better (due to legalities) - still no cooperation from Apple.
Luckily all of this will be illegal in the EU thanks to the Digital Services Act, developers will have the right to know the exact reason for a rejection, and Google will need to provide real human support.
there are many completely valid and completely unactionable reasons for rejecting people. Yes this might make it a bit better but it's very hard to make someone who doesn't care about helping you help you. Even regulation can just make them do the minimum.
What I'm hearing is there's a hell of a European market to cater to USA and other regions to host apps, and then play hardball in getting real answers.
I'm sure they'll manage the process so that it so that it's a powerless human reading an AI's decision back to you. There's no way to legislate wanting to do a good job.
Our experience with this has been the complete opposite. Apple's reliance on real human reviewers was precisely the issue for us. Your mileage may vary by a lot depending on the region you operate in.
Google's process, while not perfect, made it at least transparent that the process is going to take a while. And at least in our case, the process involved some real people at the end to point out the specific concerns that actually lead to actionables.
Apple's process is slow, and seems to be worse in my region; it's clear that they're severely understaffed here. We spent a good 30 days trying to fix a crash, and they were all spent for either submitting a new app version to Apple, waiting for the review to finish, getting it rejected for some very vague reasons, and waiting for a response from them to elaborate their reasons for the rejection.
Sometimes you have to change the code of the privacy policy page, because the AI might have problems parsing it correctly. Here is Luke from LinusTechTips talking about the problems with their Floatplane app: https://www.youtube.com/watch?v=J8iy4qYONAc&t=941s
The pushbullet article indicates an appeal succeeding doesn't mean the issue was fixed to the reviewer's liking. So I wouldn't assume the correlation that LTT's appeal succeeded because of what they did. Google's review process seemingly does not comply to logical reasoning.
Maybe, but he talks about sending it in a few times and only after changing the page's loading behavior it got accepted. Therefore, I don't think there were human reviewers involved at all, otherwise why not spell out the problem directly? Would save everyone's time and reduce the number of interactions.
"Your app was rejected because our crawlers refused to read it" is more accurate but makes Google look incompetent - even if there's legitimate reasons for crawlers to not follow redirects or execute JavaScript.
It looks like some types of reviews might be lazy: the app is accepted after an automated scan, then placed in queue to let human reviewers check it at later date.
This is actually my biggest takeaway from the article.
One time a project I was on got booted from Google Play. Then we did an appeal, they would let us back in! Yay! And we'd have to pre-appeal our next try.
But, we could not use the same Name or Namespace (com.company.project) because those were locked. They are keeping the blocked in, with notes.
Our fix was to refactor the namespace in the code, change product & company name. Jk, we just abandoned Google Play, wasn't worth it.
Was it due to copyright/trademark hit on the namespace/name? I saw that once before on a very large app 5 years into it's life on google play (I assume they implemented this copyright check job circa early 2018 based on that). Was a simple "we own the domain and here is the proof" reply and it was reinstated without further issue.
I had the unpleasant experience of submitting an extension to Google Chrome Webstore. Here is a summary:
1- Submit an update
2- Wait a week for it to be approved
3- Publish said update
4- Forget about it and move to working on something else for a few days/weeks
5- Get a random rejection email with a bogus claim and 14 days to "fix it" or the extension is removed
6- Drop everything in my sprint so I can handle this. No actual code change was required, just a series of Kafkaesque support forms and email exchanges.
After 3 or 4 rounds of this, I created a template response with a history of previous interactions and arguments and sending those became part of the routine ...
Summary. "The prisoners were executed in a summary fashion."
Also means brief, concise. I guess a summary execution (which means without trial if I understand correctly) is a briefer process than an execution with a trial…
Would also properly qualify the rejection of an extension from the Chrome store, I guess, to go back to the main topic.
(yes, found out by translating from French :-) - sommaire also means basic, rudimentary, now I wonder what made us use this word for executions - the brevity, or the basic aspect, sounded like the latter to me in history lessons)
I worked with the extension Webstore and the Android Play Store. The Webstore is absolutely way worse.
We took the resolution really seriously at first, and we tried our best to find the issue and fix it, but then we realized we had about the same resolution rate if we just changed a random character in the codebase and resubmitted. We had contacts at Google, but even they couldn't tell us what was wrong.
Play Store was/is much better, but we aren't dealing with complicated phone APIs, just basically a React Native app with REST calls. We rarely have any issues getting rejected, and when it is, we get very fast turnarounds on emails.
Chrome Web Store reviewers leave a lot to be desired. My only effective strategy over the years has been to shame them in public and let them know that our interactions are immediately published across the web. You have to be relentless, otherwise they will destroy a decade of your work in a snap.
These threads will surely give PTSD to any extension developer:
And this right here is why we shouldn't let Google, Apple, or Microsoft dictate what software we're allowed to distribute and run.
I wouldn't be surprised if Google put you through the gauntlet because your extensions either touch their products, or because they offer similar functionality.
It is really hilarious to me that Google is making PB jump through hoops for this. Google is vacuuming vasts amount of user data without any explicit user consent at all. It's just buried in some encyclopedia length ToS.
People should just copy-paste Google's TOS and Privacy Policy as their own. After all, Google's own apps on the Play Store surely comply with the Play Store's policies and the AI gremlins that enforce it will have Google's own apps in the "always approve" training bucket.
Last time I read it, it wasn't actually all that long. It was just full of qualified language like "in some circumstances such and such could be collected" and "Some Google services may do this". At the end of it, it was entirely unclear to me what Google actually did collect, but "services may do this" is really no different from "services can do this" and the result was essentially little more than "we can collect every bit of information you send to us, which we may or may not do". The qualified language was engineered very carefully to make it sound not like that.
As someone that used to work on the Play Store team many many moons ago... a lot of that was outsourced to overseas which resulted in much slower response time. Here stateside we had a lot of metrics in place to fast response. Typically your app would get reviewed the same day. Not sure what it's like now but the managers were incompetent back then even so.
My experience has been that the Play Store does have relatively quick review times (usually under a day). But the feedback given upon rejections is often so poor that it doesn't help much. As it can often take several trial and error submissions to resolve the issue.
Only for app updates in my experience. Publishing new apps takes ~7 days for years now. If I remember right, it started with Covid but it never improved.
> the managers were incompetent back then even so.
This. So. Much. This.
We go round and round about specific policies at corporate or civic levels. We hash it all out and pat ourselves on the back that we’ve at least proposed how whatever the issue of the moment might be improved.
But we never come to the basic generic issue. That large swaths of decision makers should not make the decisions they do.
I remember there being a case where a developer’s app got banned because they used the word “windows” in the play store description and Google considered this as a third party trademark violation. The developer was referring to house windows, not the operating system…
EDIT: Ignore this comment, I thought I knew what PushBullet was but I was mistaken.
Pushover is what I've used for as long as I can remember, I bought the app so long ago that I can't even remember what I paid. It's decent, a little basic though.
Recently I've just been using a Discord server since that's trivial to setup and I can get notifications on desktop and mobile easily. I just have 1 channel per "thing" that might want to alert me and then grab the webhook url for that channel and then I'm good to go.
I usually drop a "push" binary in the ~/bin folder on my machines (which is in my path) so I can do:
This is one of the main reasons I stick with Android, both as a user and as a developer. At this time, Google is still slightly more lenient than Apple is on what apps can do, and this allows my phone/tiny computer to be more functional and usable.
1) Pushbullet is frequently 'randomly selected' for extra scrutiny (TSA style) because it competes with some offering from Google or a preferred partner.
2) The review algo simply diffs the resubmission with the previous version and if there are changes 'near' any of the keywords from the violation, it gets approved, until the next 'random' scan.
Pushbullet is directly competing against google's "messages" app. They have the exact same use case. Note that Messages does not display such prominent markers that it's uploading stuf to google server yada yada, probably because it is immune to play store verification.
Or just because it looks at SMS. Few non-malicious apps have a reason to look at SMS and it's very high value data for malicious ones, no surprise the AI model misclassifies the one app with a perfectly legitimate use. It should be whitelisted but hand tweaks to algo results are probably taboo at Google.
> Your app did not receive a deliberate analysis by a human leading to the violation notification. There is no one to debate. There is no opinion at all. Your app simply didn’t look enough like the AI’s training data. (...) your goal is to look as much as possible like the training data. Unfortunately, this can be easier said than done since we do not have access to the training data.
A solution will be to have an AI submit modifications to the other side's enforcement notifications. Robots talking to robots. What a world.
Outside of the implications it might have for the economy built up around SW dev, it's significantly better that AI modifiers deal with AI masters, than human modifiers with AI masters. Scary either way.
I suspect it is actually an army of underpaid contractors, and that the inconsistency is a result of each flag and update getting looked at by a different contractor.
Ugh, this happened with a Shopify plugin of ours. Got flagged for missing something which the screenshots clearly showed was there. Resubmit enough times and it passes.
Eh. This looks like pushbullet just got a different reviewer once that approved it. I imagine (atleast apple does) the reviewers are assigned a submission and any new update - gets you the same reviewer. BUT! IF you submit over and over, you will catch this person on vacation or sick, then Approved!
With a net income of $76 billion USD in 2021, I beg to differ.
Google just has so much money sloshing around they don't notice or care if they lose a bunch of revenue over stuff like this. There's no business pressure to retain customers. Even with the news from the other day that profits dropped: it's still more than what they did a just a few years back.
Almost all these tech companies have very high profit/per employee; the idea that they can't afford a small army of human support people is just not the case; they just don't because they don't have to.
Starting around January, our app (Dominion[1]) has randomly had updates rejected (including one that _delisted the existing app_) because of our app description. We make some irrelevant changes and resubmit and, so far, it's been accepted each time. We've had the same description for over a year/10+ releases before.
The latest rejection:
>>>
The app title or description does not accurately describe the app’s functionality.
Issue details
We found an issue in the following area(s):
Full description (en_US): “▪ Tutorial & Rules ”
<<<
So we changed this to:
▪ In app Tutorial & Rules
And it passed. Every release is just a bucket of stress that we are going to lose N-days of revenue again for no obvious reason.
The situations have more in common than you might think. In both cases, you accept the non-negotiated deal offered to you unilaterally by your owners, or you accept zero revenue.
They're very different scenarios, because throughout history sharecroppers have almost always been "stuck" in their situation with no hope of relief, whereas app developers can realistically just go do something else.
When I lived in Asia as a white guy I was regularly the target of "racism": inflated prices (I was earning local salary), you're automatically "in the wrong" in any conflict even when you did nothing wrong, being a target of theft and government corruption, sometimes just general hostility. But it's not really the same "racism" in the same sense that, say, a black person in the US experiences it, as I can just choose to leave, whereas a black person in the US can't really. In spite of the similarities, in the end the experiences are not the same at all.
This makes all the difference. I'm not saying that what Google is doing is right, but it's just not the same thing at all.
At the best, it's a thought-provoking analogy. At the worse, it's a tasteless comparison between software engineering (overwhelmingly lucrative, mostly filled with otherwise well-off people) and a legal loophole for slavery.
Sure, it’s just the thing you do where you take all of the former slaves, keep them working on the same land, and pay them a pittance so they can’t leave. Hum.
Countries and even states not your own. Not to mention the successor to the underground railroad was a thing, people can move when sufficiently motivated.
Basically they are saying to stop putting your app on the app store and letting google take a large % of the app and letting your business be dependent on another business.
In this case the landlord is Google, and you are the sharecropper, giving a share (30%) to google to be allowed to use the play store.
Sharecropping originally refers to a process where a landowner would let people farm their land in exchange for a portion of the yield. It has negative associations with post-slavery exploitation of black farmers as well as poor farmers in general in the 1800s and early 1900s. In this setting, it's being used to compare the practice of hosting and selling your app on someone else's platform, with those same connotations of exploitation.
What you lose then is the auto-update.
You can of course make the app nag about installing a new version when available, but it works much, much worse.
Yeah I wondered that or the bullet character too. The thing is we referenced other apps that used this exact formatting. But yeah, could just be a bug that was introduced at the beginning of the year that hopefully they can figure out and fix.
I've been having the same issue with an app. Random rejections with a single line copy-pasted from the (genuine) feature list in the app description. In this case the lines just start with a regular dash ("-").
This together with the sometimes 10+ day review times makes it impossible to maintain an app on the Play Store now.
I find it incredible that Google's sharedholders did not do anything about the company just plain losing money "here and there" which probably adds up to billions.
Just because someone wants to get promoted by making another half baked pseudo-AI to check apps, or someone making the 6th chat program (sorry, all people quit already after the 3rd change).
If you don't mind some off-topic feedback on the Dominion website - have you considered making the Tables screen default to "New" only? At busy times, that screen consistently lags for several seconds while displaying hundreds (thousands?) of running and finished games. It's always a pain to wait for it before de-selecting "Running" and "Post-Game".
Let me know if that doesn't work. I used to work for them (only to make the release deadline). I can contact the creator directly if necessary. But the forum is probably the better route to take.
"Pushbullet connects your devices, making them feel like one." It's a "sync" program. Pushbullet talks to a lot of things and manipulates a lot of the user's data. So it's inherently a security risk.
Google also has a "sync" program, which syncs things within the Google ecosystem. Google doesn't want others encroaching on their domain. Nor do they want easy import and export from their ecosystem. Although, unlike Apple, they don't come right out and say that.
"If we only published the guilty than no one would be afraid" - attributed to Lavrentiy Beria.
I'm starting to think the reviewers have a quota of rejection to fill up and they reject apps randomly over some arbitrary concerns to meet it. Or maybe just to show they are doing they job. Or worse, the app store off shore validations, so the sub contractors script it to reject random stuff to pretend they have humans behind it.
Can someone explain why both the Google Play Store and the Apple App Store give opaque explanations for rejections? Why don't they just tell developers what's wrong and what needs to be fixed instead of pointing to some broad rule and forcing an interpretative song and dance?
I think they are using automation in detecting "violations" perhaps, given the other commentors did seemingly no-op updates and resolved things -- and any pushback would show the wizard behind the curtains, so they keep it vague as possible?
Unless someone who actually works behind the scenes can chime in.
While I think it would benefit Apple or Google as a whole to explain their reasoning clearly, it'd make things harder on the app approving teams, who probably don't want to do this for a number of reasons: it'd take more time, it'd expose inconsistency/mistakes/incompetence (why was this okay last time but not this time?), and worst of all, it'd lead to the organic creation of a binding network of labyrinthine precedents.
Whilst I don't agree with the opaqueness policy, I understand why it's in place.
It's because it leaves them at risk of using previous precise answers to others as precedents for future cases. Being opaque allows them to not be too committed, and outside of situations like "but you accepted XYZ app which does exactly the same, I don't understand"
You can still claim XYZ app does what you did and didn't get punished by that, but they can never admit it in paper/words.
Yeah, I think this is probably the right answer. I once worked on an iOS app that took about 5 cycles of "guess what's wrong?" -> submission -> rejection before we got it to pass. Each time, we asked "Can you just please tell us what to fix?" and each time the answer was "refer to rule x." So frustrating.
Scammers will try to skirt rules by making sure to adhere to the letter of the law, even if it’s plainly obvious they are violating the intent of the rule in question.
Rule 407b: no real money gambling apps
Scammers: it’s not real money. It’s Linden Dollars. Or our company script. Or our new NFTs. You can’t reject us.
Should the rule have to list out every single thing that could possibly used as currency? Because there are people who will argue that point.
Yep, anti-fraud and anti-scam is an exercise in game theory.
The more explicit you are with the rules, the more specific bad actors will try to weave around them. It sucks because it means the scalable, machine-assisted review process comes up with more false positives, but it's a two sided market and the marketplace owners care more about the users than the devs.
I feel like the U.S. tax code is a good example of when you try to go more explicit with the rules.
Maybe theres a way to functionally build up towards the same destination by collecting feedback and accepted changes. I don't know how that integrates with law, but is there something that influences the legal implications beyond what this kind of system would cover (provided a sufficient number of samples)?
Isn’t that unethical though? Preserving the right to make arbitrary decisions and favor some people over others? Most of the entire human history of conflict seems to be because of this reason of arbitrary unfairness.
What you're referring to is the application of power, and their retention of arbitrary power, specifically.
Ethics is if they used that power for abuse or an unethical goal, or to acquire an even larger amount of arbitrary power.
Pragmatically, it's their app store, and they need to retain a non-trivial amount of power to police it. It's a requirement of ownership. If they don't do so, it will devolve to an even worse garbage dump, and rather quickly.
We're of course going to complain about inexplicable rulings, things we don't agree with, etc. but that doesn't change the equation unless they get so obnoxious that other places are more attractive or it violates some law.
Isn't that just ethics at a higher level? If their goal is to create the most value in the world with the minimum harm, that's pretty much what they'd be doing - considering their resources are limited.
For the one in 100k poor guy who got on the bad side of the AI this seems like a raw deal, but if you tweaked the system to avoid it, you'd probably end up with something 5 times as expensive and 10 times as slow. Queues of weeks to get your app approved kind of slow.
Keep in mind, the behavior we’re seeing doesn’t require AI. All it requires is a bunch of poorly trained employees (contractors?) whacking at buttons after reading a policy which is worded in broad terms.
They want to be able bend/break their rules for AAAA apps. If those were publicly disclosed they could be called out for the hypocrisy and subject to regulatory intervention.
The same reason they are not thrilled about support in general: Manual labor is expensive, and at the scale that Apple or Google operate, the amount of abuse and unwarranted complaints you receive at high traffic, low entry barrier, outward facing services is absolutely insane and can not realistically be shouldered without heavy reliance on tools and templates.
But how can it be hard to make a bot produce the input it flagged?
I can see that if you are talking about humans asking them to compose detailed and specific reports has costs. But we're talking about machines, not humans.
Basically all anyone is asking for is a stack trace so they can identify and debug the issue. I don't understand why that's unreasonable for a bot.
It's like a complier that aborts with nothing more than "syntax error". Most people know compilers can be much more helpful than that.
First off, there's no human involved in the first couple passes with this. Also bad actors could then use that detail to tweak things and get around policy. It's not a great answer either but possible.
In my experience AppStore Review is usually pretty direct. They tell me I violate this and that because of these things, and even include screenshots where the violation is
The (plausible) speculation in the article is that the reviewers "don't speak English" because, being machine-learning models rather than human beings, they don't speak any language at all.
Yes, it's unfair by design, while still giving the illusion of fairness. If they obfuscate the process and the rules, some parties will be falsely flagged. But the provider can also unfairly allow certain parties to violate the rules, while pretending that there is some secret rule that means they didn't violate anything. It's not the ONLY reason, but it's a big one.
I wouldn't lump Apple in with Google. In my experience they are extremely direct, and very quick to put a human on the other end of any message. Google, on the other hand, is a black box until the end - if you don't have backchannel contacts or a "friend" at Google, good luck getting any support.
I'm convinced that the only way this situation will improve is via legislation. There are simply no other sufficient incentives since strikes/bans/policy enforcement is uniformly broken across the large players.
Commercial speech is not subject to free speech laws in the US, so that is sounding like an uphill solution.
An alternative power-broker such as F-Droid (for Android app stores) becoming more popular, somehow, and also following a Code of Conduct for App Stores that we in the dev community maintain, could be satisfactory, though also quite an uphill battle.
From most friends and colleagues I know that most of these rejected updates simply go through if you resubmit it a second time a day or two later.
Somewhat frustrating, but most of the times the issue was just that the apps were already compliant, but the reviewer on Apple/Google side was just not carefully checking
After dealing with booth Google and Apple for a couple of years I cannot express how much better the Apple experience with an actually human you can communicate with on the other end.
To whomever thinking about starting a business relying on publishing through the Play Store, please think twice.
Is there any evidence that there's any causal link here? Like, it seems like to me it could just be the act of changing something — anything — and the output from review is just a roll of the dice. Sometimes you change something, and it's approved, but given the frequency with which these sorts of articles crop up on HN, I don't think I'd assume that the change necessarily meant anything more than "they changed it".
… of course, it would help build confidence that there is a causal link if Google would clearly articulate their reasons for rejection.
235 comments
[ 7.1 ms ] story [ 267 ms ] threadThis & the other apps had it live for months, the others are still fine, just this one app now can't get updates. And we simply can't make it better (due to legalities) - still no cooperation from Apple.
Google's process, while not perfect, made it at least transparent that the process is going to take a while. And at least in our case, the process involved some real people at the end to point out the specific concerns that actually lead to actionables.
Apple's process is slow, and seems to be worse in my region; it's clear that they're severely understaffed here. We spent a good 30 days trying to fix a crash, and they were all spent for either submitting a new app version to Apple, waiting for the review to finish, getting it rejected for some very vague reasons, and waiting for a response from them to elaborate their reasons for the rejection.
Your thought is that mentioning that the necessary data is sent to https://api.pushbullet.com instead of just "Pushbullet Servers" might help?
I had not considered this but it is an interesting idea.
In our case, Google was claiming we were sending contact information to a URL corresponding to our static landing page.
In fact, we didn't even upload contact information anywhere.
This is actually my biggest takeaway from the article.
But, we could not use the same Name or Namespace (com.company.project) because those were locked. They are keeping the blocked in, with notes.
Our fix was to refactor the namespace in the code, change product & company name. Jk, we just abandoned Google Play, wasn't worth it.
Working on an app right now that is very close to the industry and we're really worried about a rejection because of that.
Also, if I had known the block would lockout my name/namespace I would have entered with a throwaway, then get the real one in.
We moved away from needing an App and now keep it all web.
It's not impossible. But both were demanding changes to the app and other hoops that just kept increasing the cost to get on the platform.
We had a smaller budget than Pax.
https://www.theverge.com/2020/6/1/21274431/pax-web-app-era-c...
1- Submit an update
2- Wait a week for it to be approved
3- Publish said update
4- Forget about it and move to working on something else for a few days/weeks
5- Get a random rejection email with a bogus claim and 14 days to "fix it" or the extension is removed
6- Drop everything in my sprint so I can handle this. No actual code change was required, just a series of Kafkaesque support forms and email exchanges.
After 3 or 4 rounds of this, I created a template response with a history of previous interactions and arguments and sending those became part of the routine ...
Summery means "characteristic of or suitable for summer", as in the season
Summary is the word you meant to use
Also means brief, concise. I guess a summary execution (which means without trial if I understand correctly) is a briefer process than an execution with a trial…
Would also properly qualify the rejection of an extension from the Chrome store, I guess, to go back to the main topic.
https://www.wordreference.com/fren/sommaire
(yes, found out by translating from French :-) - sommaire also means basic, rudimentary, now I wonder what made us use this word for executions - the brevity, or the basic aspect, sounded like the latter to me in history lessons)
Thanks to wordreference above all. You might have meant it as a joke initially, but I learned something.
We took the resolution really seriously at first, and we tried our best to find the issue and fix it, but then we realized we had about the same resolution rate if we just changed a random character in the codebase and resubmitted. We had contacts at Google, but even they couldn't tell us what was wrong.
Play Store was/is much better, but we aren't dealing with complicated phone APIs, just basically a React Native app with REST calls. We rarely have any issues getting rejected, and when it is, we get very fast turnarounds on emails.
Play store had a much lower
These threads will surely give PTSD to any extension developer:
https://github.com/dessant/search-by-image/issues/57
https://github.com/dessant/search-by-image/issues/63
I wouldn't be surprised if Google put you through the gauntlet because your extensions either touch their products, or because they offer similar functionality.
This. So. Much. This.
We go round and round about specific policies at corporate or civic levels. We hash it all out and pat ourselves on the back that we’ve at least proposed how whatever the issue of the moment might be improved.
But we never come to the basic generic issue. That large swaths of decision makers should not make the decisions they do.
Do big-earners on the app store get higher quality service?
Pushover is what I've used for as long as I can remember, I bought the app so long ago that I can't even remember what I paid. It's decent, a little basic though.
Recently I've just been using a Discord server since that's trivial to setup and I can get notifications on desktop and mobile easily. I just have 1 channel per "thing" that might want to alert me and then grab the webhook url for that channel and then I'm good to go.
I usually drop a "push" binary in the ~/bin folder on my machines (which is in my path) so I can do:
https://medium.com/@daniel_11666/331c98270ec4?source=friends...
1) Pushbullet is frequently 'randomly selected' for extra scrutiny (TSA style) because it competes with some offering from Google or a preferred partner.
2) The review algo simply diffs the resubmission with the previous version and if there are changes 'near' any of the keywords from the violation, it gets approved, until the next 'random' scan.
the experience of publishing apps to Google Play is really awful.
After developing native apps for years, we'll be publishing our next project as a PWA for this reason alone.
A solution will be to have an AI submit modifications to the other side's enforcement notifications. Robots talking to robots. What a world.
https://twitter.com/jamonholmgren/status/1462955101899788294
Google just has so much money sloshing around they don't notice or care if they lose a bunch of revenue over stuff like this. There's no business pressure to retain customers. Even with the news from the other day that profits dropped: it's still more than what they did a just a few years back.
Almost all these tech companies have very high profit/per employee; the idea that they can't afford a small army of human support people is just not the case; they just don't because they don't have to.
> I really really need to make Google happy.
The latest rejection:
>>> The app title or description does not accurately describe the app’s functionality. Issue details
We found an issue in the following area(s): Full description (en_US): “▪ Tutorial & Rules ” <<<
So we changed this to:
▪ In app Tutorial & Rules
And it passed. Every release is just a bucket of stress that we are going to lose N-days of revenue again for no obvious reason.
[1] https://play.google.com/store/apps/details?id=com.templegate...
When I lived in Asia as a white guy I was regularly the target of "racism": inflated prices (I was earning local salary), you're automatically "in the wrong" in any conflict even when you did nothing wrong, being a target of theft and government corruption, sometimes just general hostility. But it's not really the same "racism" in the same sense that, say, a black person in the US experiences it, as I can just choose to leave, whereas a black person in the US can't really. In spite of the similarities, in the end the experiences are not the same at all.
This makes all the difference. I'm not saying that what Google is doing is right, but it's just not the same thing at all.
Bigotry of low expectations.
The system definitely was not confined to Reconstruction
At the best, it's a thought-provoking analogy. At the worse, it's a tasteless comparison between software engineering (overwhelmingly lucrative, mostly filled with otherwise well-off people) and a legal loophole for slavery.
In this case the landlord is Google, and you are the sharecropper, giving a share (30%) to google to be allowed to use the play store.
This together with the sometimes 10+ day review times makes it impossible to maintain an app on the Play Store now.
Just because someone wants to get promoted by making another half baked pseudo-AI to check apps, or someone making the 6th chat program (sorry, all people quit already after the 3rd change).
If you don't mind some off-topic feedback on the Dominion website - have you considered making the Tables screen default to "New" only? At busy times, that screen consistently lags for several seconds while displaying hundreds (thousands?) of running and finished games. It's always a pain to wait for it before de-selecting "Running" and "Post-Game".
Google also has a "sync" program, which syncs things within the Google ecosystem. Google doesn't want others encroaching on their domain. Nor do they want easy import and export from their ecosystem. Although, unlike Apple, they don't come right out and say that.
"If we only published the guilty than no one would be afraid" - attributed to Lavrentiy Beria.
Unless someone who actually works behind the scenes can chime in.
It's because it leaves them at risk of using previous precise answers to others as precedents for future cases. Being opaque allows them to not be too committed, and outside of situations like "but you accepted XYZ app which does exactly the same, I don't understand"
You can still claim XYZ app does what you did and didn't get punished by that, but they can never admit it in paper/words.
Scammers will try to skirt rules by making sure to adhere to the letter of the law, even if it’s plainly obvious they are violating the intent of the rule in question.
Rule 407b: no real money gambling apps
Scammers: it’s not real money. It’s Linden Dollars. Or our company script. Or our new NFTs. You can’t reject us.
Should the rule have to list out every single thing that could possibly used as currency? Because there are people who will argue that point.
The more explicit you are with the rules, the more specific bad actors will try to weave around them. It sucks because it means the scalable, machine-assisted review process comes up with more false positives, but it's a two sided market and the marketplace owners care more about the users than the devs.
I feel like the U.S. tax code is a good example of when you try to go more explicit with the rules.
What you're referring to is the application of power, and their retention of arbitrary power, specifically.
Ethics is if they used that power for abuse or an unethical goal, or to acquire an even larger amount of arbitrary power.
Pragmatically, it's their app store, and they need to retain a non-trivial amount of power to police it. It's a requirement of ownership. If they don't do so, it will devolve to an even worse garbage dump, and rather quickly.
We're of course going to complain about inexplicable rulings, things we don't agree with, etc. but that doesn't change the equation unless they get so obnoxious that other places are more attractive or it violates some law.
For the one in 100k poor guy who got on the bad side of the AI this seems like a raw deal, but if you tweaked the system to avoid it, you'd probably end up with something 5 times as expensive and 10 times as slow. Queues of weeks to get your app approved kind of slow.
I can see that if you are talking about humans asking them to compose detailed and specific reports has costs. But we're talking about machines, not humans.
Basically all anyone is asking for is a stack trace so they can identify and debug the issue. I don't understand why that's unreasonable for a bot.
It's like a complier that aborts with nothing more than "syntax error". Most people know compilers can be much more helpful than that.
A good analogy is dating. What they’ll allow you to get away with is highly dependent on how attractive they find you, from a business standpoint.
An alternative power-broker such as F-Droid (for Android app stores) becoming more popular, somehow, and also following a Code of Conduct for App Stores that we in the dev community maintain, could be satisfactory, though also quite an uphill battle.
Somewhat frustrating, but most of the times the issue was just that the apps were already compliant, but the reviewer on Apple/Google side was just not carefully checking
… of course, it would help build confidence that there is a causal link if Google would clearly articulate their reasons for rejection.