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.
"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.
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.
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).
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.
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.
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.
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.
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.
It's really sad that software distribution has deteriorated into this submissive permission-seeking practice of pleasing an opaque moving target, as a sort of disorganized morality police that claim to act on behalf of the users. And not only that, but we still have 0 standardization or agreed-upon APIs so devs generally have waste heaps of time on per-platform idiosyncrasies that has nothing to do with business logic. We do have cooler tech today, but that is despite, not because, this suffocating and unsustainable selection of walled "gardens".
Should developers come together with a foundation for software distribution ? An appstore, members are individual or corporations, governance through election of a board by the members (see Debian and Openstreetmap)... And a little help from the European Comission who'll be happy to have a neutral channel to impose on the monopolists !
I don't like another app store. Not as a user, nor as a developer.
I would prefer first-class support for self publishing.
Want to install some app, open some-app.com in a browser, and click "download" button.
The security issues should be solved with technical measures on the OS side. Modern phones have sufficient resources for proper sandboxing at the OS level. Modern ARM CPUs even support hardware-assisted virtualization. Virtualization might be an overkill for the problem though, there're simpler ways, like abusing multi-user nature of all modern OS kernels.
Modern phones have sufficient resources for verifying digital signatures. We already have relatively decentralized global infrastructure for that, not too expensive to buy a signing certificate from verisign/comodo/digicert/etc. Can be optional, as long as end users see a clear warning "you're installing an app of unknown identity. Continue?"
Software updates don't need to be centralized either. When a user installs 100 apps from 100 publishers, I think it's OK to run 100 small HTTP requests to web sites of different publishers, couple times a month when checking for updates.
Second this. The existing trust system of the web is much preferable to inventing closed store. Plus the web isn't going anywhere.
Here's what should happen:
Some site says "get our app". Click. A banner shows up showing the app name, icon, screenshots?, highlights the domain.
It declares what capabilities it needs, but most permissions are temporary and on-demand. Apps that have sensitive perms (mic, camera) are highlighted whenever they use it.
Aggregators, blogs, (heck even governments), trust pilot can all have their own ad hoc review systems and warn against whatever, for those that want. You could even have a pre-installed whitelist for extra safety for non-techies for all I care.
Ready to download? Just press get app. There can even be an option to run the app once if it's something stupid that should have been a web page. Once downloaded, the signature is verified against a tls cert.
> Some site says "get our app". Click. A banner shows up showing the app name, icon, screenshots?, highlights the domain.
> It declares what capabilities it needs, but most permissions are temporary and on-demand.
Remember when Android would give you a list of permissions that an app needs and everyone clicked through it because it was impossible to make an informed decision on what the app did?
Absolutely. This is partly a UX problem and partly user education. But yeah requiring all permissions upfront was a terrible model, but that was long ago.
I personally like the idea of repositories that F-Droid uses. Each app vendors could have their own repos that users subscribe to, but one of the strength you give up by moving away from a centralized app store is discoverability, but that didn't stop us from having great desktop softwares in the past, all distributed by the vendor/developer.
F-Droid (the service) is focused on providing apps that are compiled by them using the original source code (they can redistribute the developers' APK if the build process is reproducible).
F-Droid (the client) is simply a way to easily access the F-Droid repository (which is there out of the box), but anyone can create a repository and male it available to be registered in the F-Droid client as another source, completely independent from the F-Droid service.
I would prefer first-class support for self publishing. Want to install some app, open some-app.com in a browser, and click "download" button.
Since the parent mentioned Debian: this is the model that Debian provides (and yum as well), and Ubuntu extensively uses: https://help.ubuntu.com/community/AptURL
Open some-app.com in a browser, click the apt:// button, and the system will not only install the requested app, but also use the configured channel for updating your apps.
There are numerous improvements to be made in this area, for example to automatically pin a package to an origin, or to limit third-party origins to only installing in /opt/$origin, but the mechanism has been available for two decades.
If one could solve the app validation problem with OS enforcement, Apple and Google certainly would have already. (Though both have made incremental progress). They spend a huge amount of resources in the app review pipelines.
In particular, validating privacy policies is an unsolved area. How would one enforce that an app is allowed to access health data but doesn't forward it to the internet? One might envision some language environment that can track taint-style the flow of data through an application, but this seems beyond state-of-the-art.
In future one can only do API calls via a Google owned firebase like environment. Your services need to run there and each service is reviewed and constantly monitored by smart AI bots who can detect abuse and flag your services as dangerous if needed and in result reject and remove your app from the app store. You can appeal against very smart AI which sometimes tell you what to do to resolve the issue by sending you a link of 1000 pages of terms and conditions. Google finally added a personal contact phone number for a developer. You can request support 24 hours per day. The extremely intelligent and responsive AI will solve every issue for you.
> How would one enforce that an app is allowed to access health data but doesn't forward it to the internet?
User-mode code can’t do any IO or networking by itself. Instead, apps call OS kernels asking to open files or sockets for them.
It’s impossible to disable forwarding just for the health data, but it’s easy for an OS to completely disable any TCP/IP networking for an app which uses health data.
Apple and Google are struggling with that problem because in their ecosystems many developers rely on in-app advertisements, and Google is even running its own ads network.
> One might envision some language environment that can track taint-style the flow of data through an application, but this seems beyond state-of-the-art.
> I don't like another app store. Not as a user, nor as a developer.
> I would prefer first-class support for self publishing. Want to install some app, open some-app.com in a browser, and click "download" button.
Self-publishing, web-style, is suboptimal, because developers are never concerned about anything but their precious software. They're essentialy primadonnas who think that world revolves around them and computers around their "app". The results are predictable, resource utilisation of js-heavy websites is tested on high-end boxen with a single tab opened and various "self-publishing" bundles like Flatpack have 200× size vs normal deb packages. Well, I want to open more than 1 tab and install more than 1 software package, not necessarily on maxxed out machine.
And this is just technical issues, because after them there are social ones. DFSG and Social Contract are there for a reason, because far too many times software authors had in mind something other than user's best interest (two days ago there was a thread which started with lenovo, but quickly filled with plenty of other examples).
Maybe it's a good time to remember that PC stands for Personal Computer, not App Developer's.
Some programs need gigabytes of memory, and all CPU cores, for legitimate reasons.
I believe the actual problem here is the UX. Modern operating systems aren’t doing a great job communicating per-app resource consumption to end users.
I think that can be solved at the OS level. Operating systems actually collecting that data: various task managers, powertop, netstat, etc. But they fail to present these values in a way which would alert users.
If the UX problem is solved, users wouldn’t be using resource-heavy apps for long. Then software developers would be motivated to pick better technologies for their apps, and/or optimize their code.
FYI you can host an f-droid repository of your own for your application, and f-droid users can keep up to date with it. If you host your own repo you don't even have to publish source code.
However there are other issues than security ones. Some stuff is not allowed, like for example doing some grown-up things (sorry to be so vague). Self-publishing only works if a third party efficiently controls forbidden things.
It would not have to be a public-facing destination (for downloads / marketing info). I would encourage this: it could operate instead like a repository, from which it could republish to other app-stores. So that way one would avoid the varying security and cost differences of each app store destination.
We wouldn't need an app store or any kind of walled garden if the operating system were actually designed with proper security in mind. As it is, apps need to run with too many privileges which is why filtering out spam and dangerous apps from a store is a "value-add".
Apple and Google are excellent at moderating against malware, and that is a serious barrier to entry. But a bunch of publishers fed up with paying Apple and Google might be motivated enough to invest in an equivalent community infrastructure.
Sandboxing of the browser is much more important than that. Apple and Google built their own sandboxes for mobile, I think personally we should take the best open sandbox env and expand. Wasm is a great start, does multiple languages and easy to port to new platforms. Human friendly higher level capability wrappers / ACL could be built around it.
> we still have 0 standardization or agreed-upon APIs
As a former Unity Technologies employee on the in-app purchase abstraction layer, I can say that the Unity runtime abstracts dozens of platforms' (mac, windows, etc) various APIs, today. And alternatively Godot supports a different set of platforms.
So, focusing on Unity, that problem has _a_ solution, however it is another privately managed API rather than one agreed upon presumably democratically by all developers, as I knowingly naively interpret is an aspiration here.
Therefore a free open platform-API standard can be created, trivially based upon Unity's IP. [IANAL so someone else check this plz]
> software distribution
Yeah distribution does not have a technical solution. In my experience it has been handled by agencies, each with proprietary partial automation and a lot of human handholding.
TBH there are 2 big app stores, and 400+ smaller app stores of varying sizes - Microsoft, Amazon, Samsung being larger western-mindshare stores, plus hundreds of global stores with lesser centralization than e.g. the tightly controlled Apple App Store. On top of that is the "no store" model of direct installation which relies on e.g. readme's for comprehensive installation.
So, I suspect a web-driver could be built that abstracts these sites. There exists APIs for many app-stores' publishing pipelines. Note, initial publisher-registration however typically requires manual work often involving real-world bank accounts.
Therefore, from that, a publishing standard could be put out there. Something that would identify app versions, publishing tracks, app high-level service features, permissions, user-facing metadata, publishing schedules, and store-review-status workflows.
> I can say that the Unity runtime abstracts dozens of platforms' (mac, windows, etc) various APIs, today
I hear you. It's the best solution, and all credit to unity and others for doing that work. That said, I don't like it, because it's almost always a bad upfront tradeoff between fiedlity and velocity. Moreover you just end up with another layer in the stack, when we should have fewer. Half the time these things are broken, in my experience, not because of any fault of the middlemen, but because Microsoft, Apple or Google changed something in their proprietary, poorly documented code base.
A side note, working at Unity was fun because the point was not a generic solution for all programmers, but rather to make life easier for game developers so that they could focus on the creative aspect of their games. For example Not working around Google Play Library's latest unintentional goofiness around how their Android Activitys would close prematurely and send incomplete signals terminating their purchasing flows and then you as the game developer would have to somehow magically capture the now suddenly missing workflow signal and yada yada yada. So yes, I agree with you :-)
And moving the discussion further, designing a new high level platform abstraction API could include a feature that compiles this new APIs bloat away and eliminates intermediate calls.
Platform fragmentation is kind of a never going to solve it perfectly problem in my opinion. Until we have computers that write their own software to solve some end goal, humans are going to have to keep releasing patched versions of adapter layers.
> 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.
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.
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.
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?
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.
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.
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.
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.
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)?
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.
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 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.
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.
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 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
Throwaway so the Googlers don’t hunt us down. Whenever we get a violation we just resubmit a new build without any material changes, maybe a bug fix or two. We know our app review will be handled by a different person in country A this time instead of country B, or a different person down the hall, so there’s a strong chance the review passes without issue.
Violations are completely arbitrary and not enforced or closely reviewed upon resubmitting, so we put as much effort into them as Google does.
Being forced to work under these conditions feels like being in an abusive relationship.
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.
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 ...
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.
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.
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'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.
Before this, they become experts on suddenly converting to the subscription model and then just ghosting all/any development. [1][2][3]
I didn't mind them converting to subscription, I got value out of them, so I paid for the sub (even though it was one of those that removed features from the free to put them into paid and I felt a bit dirty. All good products deserve some suppporter cash IMHO)
I paid for a year. They just totally shut up shop, didn't develop a feature, didn't do a thing. I left after my year's subscription was up, sick of sticking up for them in forums/reddit etc and realising most of the complaints people were leveling and them (him?) were valid.
It's a shame to see Google treat anyone like this, but meh, that's how we felt after paying up for Pushbullet Pro which saw zero development/love after the fact and the developers who had, previously, been very vocal and supportive, go to radio silence.
I kinda support Google here, put this poor thing out of its misery.
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…
> We take seriously the security of any information stored on our servers and take all reasonable precautions to protect this information.
All reasonable precautions?
What's that supposed to mean?
You got internal policies in place that not all engineers are able to access these messages according to their contract?
This type of data should be e2e encrypted, pushbullet shouldn't even be able to decrypt it and messages should disappear from pushbullet servers as soon as the message is pushed to all devices.
I've been using pushbullet for years but now I'm considering disabling the sms sync feature, the privacy policy looks really shady and Google has all the right to call it out.
Yep, Google's communication was pretty unclear, but the developer is being repeatedly called out for the same underlying problem which they haven't addressed at all.
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.
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.
Chiming in to say I love Pushbullet. I find it invaluable for sending things between my devices.
I recently learned that it’s no longer available for iPhone and that if I get a new iPhone I won’t be able to load it onto the new device. It has kept me from upgrading. Eventually I’ll have to but it will be a sad day. I’ve seen a few alternatives but they don’t appear to have the same usability.
I have gone through the joys and pain of having an app approved and pushed live, to being teared down and removed for not meeting certain guidelines.
What frustrates me, is the reasons are very vague or don't have go into detail as to how YOUR app is in violation.
It is just a generic statement and you have to go through the hell of trial and error to figure it out.
The main ones I have faced are the following.
* Not adhering to Families policy requirements policy
* Not adhering to Google Play Developer Programme Policies
My apps are games built using Trusted Web Applications (TWA) and Google talk about the following...
"Your app must not merely provide a webview of a website or have a primary purpose of driving affiliate traffic to a website, regardless of ownership of the website. We are constantly exploring ways to enable new experiences for kids app developers. If you are interested in joining our Trusted Web App pilot for education apps, please submit your interest here"
My apps have no ads, no tracking, no analytics, they have a privacy policy, but it still gets rejected. :(
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.
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.
At this point, I can sufficiently say that the author is on point regarding AI training and I know when an extension review has been through an automated process or via a human.
How much would a private investigator charge to find someone at Google who'd talk to you about this off the record? This might be a situation you could farm out.
Obvious YC startup idea here: build an AI model that analyses app store rejections and automatically modifies and resubmits the app. Fight fire with fire.
You seem to have missed the fact that the commenter talking about Play Store issues with the Dominion App is different person at a different company, the author of TFA (who works for PushBullet).
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
[Ding]. They’d sent me another automated notice. THIRD THIS WEEK.
My work had been PATmatched for review, pending cancellation. Drat
I was already low on credits to cover food bills this week.
Car capsules filled the crimson sky of the small windows in my 10000 story apartment room, day and night the automated vehicles rolled past my window like a raging torrent. Living so high, not much to do but sit at the console.
Another automated notice from TECHCORP. Always the same. Never a human.
So insanely lacking in logic that often I’d want to scream in rage.
But actually, IT WAS LOGICAL. To the billions of learning machines, running at basement level, in windowless buildings, beyond places I’d never know; I was the anomaly.
Just wanted to say I appreciated this nice start to a story and now I have an app idea to create crowdsourced interactive fiction or at least branching fiction, one paragraph at a time.
You pay the in-app-token equivalent of $0.25 to post a new paragraph at any given node, then as other users select your node for that branch, your node rises in popularity.
Once a month, the most popular branches get paid a prize of in-app-currency for submitting good content.
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.
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...