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.
Unless someone who actually works behind the scenes can chime in.
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.
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.
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.
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.
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.
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 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 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.
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...
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.
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".
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).
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 ...
These threads will surely give PTSD to any extension developer:
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.
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
Summery means "characteristic of or suitable for summer", as in the season
Summary is the word you meant to use
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.
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
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:
./longRunningCommand.sh && push "Command finished!"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.
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.
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.
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.
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.
1: https://www.reddit.com/r/PushBullet/comments/6wby5b/is_pushb...
2: https://www.reddit.com/r/PushBullet/comments/7bjvhx/is_this_...
3: https://www.reddit.com/r/PushBullet/comments/77egnz/is_pushb...
[1] https://www.reddit.com/r/PushBullet/comments/vv844d/comment/...
> 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.
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.
… of course, it would help build confidence that there is a causal link if Google would clearly articulate their reasons for rejection.
I'm a little confused why the app version would need to access my SMS message history, send messages on my behalf, and access my contact info though.
I don't want that even if you claim to not be sharing it with anyone else...
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.
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.
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.
https://medium.com/@daniel_11666/331c98270ec4?source=friends...
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. :(
> I really really need to make Google happy.
This is not fair or just.
This is not artificial intelligence.
This is not freedom.
This is abusive.
This is capricious.
This is arrogance on the part of Google developers.
This is comparative programming designing a system to meet a standard maintained by an automaton.
This is the worst form of tyranny.
Things got so frustrating that I wrote my own guide on pushing updates to the webstore: https://getsnapfont.com/posts/avoiding-lengthy-review-times-...
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.
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