Google Warns Developers That All New Android Apps Require 3 Days for Approval
choiceofgames.com
choiceofgames.com
I think a soft 3-day review period is very reasonable, even if it comes at the cost of making launch marketing harder for developers.
Today, Google has a "timed publishing" system for app updates, allowing you to submit an app update today and schedule it to go live on a future date (after successful review). We need the same system for new app releases.
Apple, which also has a multi-day review process for new apps, allows you to submit an app for approval and then hold it for manual release. After approval, you push the button on release day, and the app goes live immediately.
Also: surprising us with this on release day is really unprofessional of them. The "we'll take more time" warning banner doesn't show up until after you submit the app. There was no way to know we had to submit early until it was already too late to act.
But, as my conversation with support showed, even after getting internal track approval, you'll need to wait another three days when you want to go live for production approval. ("It should be slightly quicker, but again we recommend three days just to be safe")
* Lack of timed publishing feature
* Lack of messaging about review until after submission
The message isn't clear and people seem to be reacting to the three day process (not the problem) instead of the messaging and features around it.
It's a pretty annoying behavior because it means that discussions often end up wildly off-topic or with a lot of comments missing the point, or just re-stating the exact same things that the article already said (often because people ask questions that the article answered, but they didn't read it).
Unfortunately there's not really any good way to fix it. We had a big discussion about this same issue on Tildes recently too: https://tild.es/gjb
"Google needs scheduled new app releases". Seems like a pretty good way to "fix" this, but I guess it wouldn't drive much traffic.
Situations simply can't be covered well in a single sentence. That's a big part of why Twitter is such a terrible platform for discussing anything of substance, there's no room for context.
I'm wondering if adding a Tweet-length summary or pull quote to some posts would help?
I come to hacker news to find out what the hacker news userbase thinks. I get a lot more value learning about a topic from the questions and answers smart people are posing to each other on a domain that isn't trying to cram garbage down my throat, even if they do end up rehashing one of the scant details or traipsing off-topic from the original submission.
Of course I live for the comments where someone who has read the article posts a concise summary.
And paywalls. Probably 1/4 of the time when I open a link "You've viewed your allotted 1 article this decade, please pay us $39.95 a month for access to our articles"
It's not easy, but nothing worth doing is. And on the plus side, the question-answer problem already has a lot of contributed work [1]. And if you have a meager SE salary's worth to contribute I'm game to have a go at it =)
[1] https://aclweb.org/aclwiki/Question_Answering_(State_of_the_...
However if you are skimming the article, reading the title, aren't particularly familiar with the topic (esp. non HN audience) it is easy to get the wrong impression. There's nothing wrong with not giving your full attention to a piece of writing, there is a lot of it out there and time is short, maximizing the value per time you get means lots of things get only a little attention.
A good article means a good title and a thesis that comes out and slaps you in the face right away. The title should be a short abstract of the whole (not bait but substance) preferably including the conclusion. The real meat of the title should be at the beginning of the title, not the end. The first paragraph should lead with a high level view of the content and the path the rest of the article is going to take.
The title and beginning of the piece should both contain the entire point and conclusion of the article and sell the reader on finishing the whole with expanded reasoning, details, and conclusions.
I guess I could change the title? But I don't know what I'd change it to.
Or something like that. Your current title doesn't indicate the problem. The first two words in mine contain the main topic and set the tone. This isn't about an extended release process, it's about scheduling the release.
As a marketer these 'launch the day the product is ready' goals don't usually get the best results. Often you burn power unnecessarily as you set activities up and then last minute delays are needed. This can loose money, goodwill with external parties and enthusiasm from the launch team. Or generally force to do things faster than you should properly plan and organise.
I always found this fast launch a bit illogical. You get one launch. Teams sometimes spend years developing a product but don't want to wait a couple weeks/months for a better launch once a product is ready.
They could also have been practicing with a simulation of the review process using real-world app submissions for a while before this, and gotten the experience from that.
Imagine you write a script which creates a spammy app (eg. no content, 100% ads). You launch on the play store, and instantly insert a few 5* fake reviews, and then for the next 10 minutes you do a heavy ad blitz all over the internet and other mobile apps to get a decent installed base.
All those users now see what 'appears' to be a brand new app, already getting decent reveiws! They install it, only to find it's junk. Many won't bother to uninstall, so the app maker gets to keep popping up modal ads and running a background service for years...
Repeat the whole process 20 minutes later with another procedurally generated app on a new account...
https://arstechnica.com/gaming/2019/03/a-dev-trained-robots-...
An interesting tidbit is that their ads had 27% click-through rate. They believe it was due to the games were much better than whatever the ad was showing, so people clicked it to get away.
- Usually under a couple days, sometimes same day
- Doesn't immediately hit the store upon passing review, instead hits "Pending developer release"
- Expedited option for critical bug and security fixes
- Preorders
Now if only they would stop those apps that trick people into crazy subscriptions.
I'd say the Android app store is a nice balance.
Also, if you want to install some other, less-well maintained app store on your Android, that's also possible (on non-rooted phones, too). Indeed, I've got F-Droid enabled on my Android.
That said, if Google ever pulls the ability to sideload apps on non-rooted phones, I'll not be happy at all.
When Fortnite was distributed outside the Play store I thought that would be the catalyst for removing side-loading permissions, only retaining them over ADB so developers would not be totally screwed. Maybe the news of that arrived too late in the Q cycle for it to be implemented. I'm sure that one day on-the-fly side-loading is going away. Maybe not in Android Q, but in R or S definitely. It's too consumer-friendly and useful! Removing it will "help user's security" while at the same time removing the ability to install 3rd party VPN-faking ad-removers or games like Fortnite that don't have to pay Google 30%.
There's no three day wait to install an APK, either.
There's a three day wait to get your app in Google's store, which isn't the only possible distribution method for Android apps.
So far this has not caused any signifficant issues - rather gave enough time for testing & caught a lot of breakage before it broke someones Fedora installation.
What's particularly annoying about the AMO case is that you can't even sideload addons on Firefox but that's a different issue.
https://support.mozilla.org/en-US/kb/add-on-signing-in-firef...
The worse part of approval delays is that they are almost never given time in development schedules made by project managers, bizdevs, marketing etc. They just absorb that few days into the dev time or take from testing etc.
In a way, having long app reviews, or delays to update, causes worse quality apps from having dev days or testing days taken from the app development cycle and rushed fixes just to get it back in the pipeline. This is a very common occurrence in app/game development. I wish it weren't this way but quality has to be fought for and it can harm the people pushing for it perceptually as 'slow'.
Basic heuristics on release for bad actors is enough, then upon launch have random reviews that check out what people are doing past the point. The problem apps are usually getting through the review by cheating and then turning on features that are dark patterns or malware type junk.
Any reviews over a day or two add to bad quality simply due to compressed timelines.
Sure, give preference to the reviewed apps in the store, put a nice badge on it when it's reviewed, add a setting to allow unreviewed apps to install, prevent kids from installing unreviewed apps, etc, but at least let me upload my app when and how I want to.
The point of the app store is to have a centralized AND TRUSTED distribution point for apps of the OS.
People can install non reviewed apps by using non-official app stores. There is good reason most people don't as these are plagued or perceived to be plagued with malware.
Not on iOS
Whether that is good or bad short term or long term can be debated separately, but it is fundamentally a shift of power away from independent developers towards a giant megacorporation. (I personally think app stores are fine but that the public has an interest in preventing any entity from having too much power, so it should be illegal to prevent sideloading.)
I want the safety and uniformity of knowing that have gone through the review process. If it not mandatory, no one will do it and I will lose the protection I have now.
Like I said you could choose to install only reviewed apps.
90% of the apps I install on macOS are not reviewed by Apple and after 12 years that has never been a problem for me.
> If it not mandatory, no one will do it and I will lose the protection I have now.
If users prefer Apple-approved apps then the dev market would shift towards that.
Add a checkbox to show apps tjat aren't approved yet.
Make it default off. Turn it off every time you leave the Play store app.
Disable it for people under 18.
If a user still wants to install the app point out the app isn't approved yet and ask for password.
There, problem solved..?
Not sure why you're being downvoted though (judging from the light color of comment) as your comment definitely isn't off topic.
And that's why folks, what the world really needs is not the open web, or open anything, but an Apple/Google/UltraMegaCorp approved whitelist of domains, for your own safety. Because Apple cares, unless it's a nation state like China, then Apple folds, because hard spun tales of user safety and empathy be damned when bottom lines are in play
Figuratively tearing up the paving is a terrible solution to a speeding problem, which most countries seem to agree with. Usually speeding instead is a fineable offense, which I'm okay with.
Reserve the right to apply a fee if you release more than X apps per Y time, or update more often than Z times in Y time. Increase the allowed fee/fine geometrically (or lower, but still exponentially) for each offending update/app, but allow keeping a few "credits" if you have a reasonable update rate. This would make it costly to be a bad actor, but still affordable the odd time you mess up and need to push out an unplanned change.
Really though Google gets a huge pass on the Android app front for the simple reason that you and your users can sideload. Yes it requires a trusted reputation, or stupid users, but google doesn't stop you from supplying your clients/customers with critical apps(or updates) as soon as they're ready.
If your app needs to launch on a specific day (it doesnt), it should have been uploaded and field tested at least a couple of weeks in advance.
In the past, we've handled this by submitting the app for review 24 hours in advance; luckily, that turned out to be just enough time to make our app go live this afternoon.
Google offers a “timed publishing” feature, but it only works for app updates, not for new apps. If Google is going to put apps through a multi-day review process, we need timed publishing for new apps as well.
And a quick word on soft launch periods: It’s ok, it’s not the worst thing, but it’s not preferable itself. Hence the need for a timed release tool.
Wow that's pretty presumptuous of you.
Or maybe it absolutely does? There are so many valid business reasons for deadlines whether due to contracts, school years, laws, whatever it is. Likewise that an app can't launch until a certain date due to licenses, agreements, tie-ins, servers, etc.
That's silly. Coordinated marketing around app releases is a big deal, and plenty of teams are cramming in features and bugfixes till the last minute.
~~~
The only thing a student can do is choose when to submit. Therefore the upload time should either be
1. given, (what a nice prof!)
2. unsurprising (i.e. on par with similar UX's of the age)
3. fuzzy (12:03am is okay, 8:57am is not)
4. determinable (e.g. via overwritable submission and a success notification)
There are a handful of important, ambiguous, and strict deadlines in the real world, so if that's what the prof is trying to teach, bravo. Or if they're trying to get students to do the test in #4. But that's rarely what's going on.
Disclaimer obviously I was one of those… X~D
(Enforcing using Google services to deliver notifications, aggressively killing background apps, limiting access to external storage, making it impossible to record calls, now this... and many other things I can't remember)
On one hand I'm happy because iPhones are too expensive and having more options is good, but on the other, this is still Google :P
I’m not saying the improvements in security are bad, just complaining about the extra hassle it causes developers! There’s probably no way to make everyone happy at once.
Nothing insurmountable, just slower and more awkward than it used to be.
e.g.: "The Google Play Store will carry out a security review on your app and list it in the store on April 17. If that doesn't happen, this policy will pay XYZ developer $1,000,000"