Obviously the article is a complaint from an app developer, but... sorry, I'm on Google's side here. Rushed, rapidly-updating, poorly-reviewed games with unvetted malfeatures are a plague. The last thing the smartphone community needs is "more apps faster".
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.
OP here. We're happy to endure a three-day review process, but if it's going to take that long, then there needs to be a way to schedule an app release.
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.
I thought the post was pretty clear on both of these things. I'm surprised that all the top-level comments here (at the time I write) are addressing only the longer review time - it seems clear enough that the real problem is that it's impossible to schedule a release properly.
So many people comment--on everything, not this post specifically--without reading anything more than the title of the HN post. They basically treat the title as a "topic suggestion" instead of reading the article itself.
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
I consider this a feature more than a bug. I don't come here for the links. They're the same links that get posted to all the other link aggregators. Often the content is disappointingly thin, poorly written, or just a ranting opinion. Usually the content is packaged with an inane amount of bandwidth-hogging privacy-invading tracking scripts and malware. I make a point of not clicking the link unless something in the comments leads me to believe it will be compelling.
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.
You're talking about reading the comments before the post. That doesn't cause problems. The issue is for people making comments, and specifically comments about the article, without having read it.
I totally get it. I'm just saying those comments don't bother me. Oftentimes they lead to a correction and more interesting conversation that, again, saves me from having to click the actual link.
Of course I live for the comments where someone who has read the article posts a concise summary.
>Usually the content is packaged with an inane amount of bandwidth-hogging privacy-invading tracking scripts and malware.
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"
Like Slashdot does? It certainly has merit, but that requires that someone actually write the summary, which is more work and injects (more) subjectivity.
That doesn't fix anything, it just changes the problem. I guarantee a popular post with a title like that would get comments saying "it already has them" from people that didn't read the article and don't know about the new review process and mandatory wait.
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.
You could make a quiz for articles using machine learning and allow commenters to optionally complete quiz questions before commenting to earn a flag that says they've read the article.
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 =)
It makes it clear if you're really paying attention, familiar with this sort of thing to a degree, and thinking actively about what is going on.
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 believe the post makes it very clear, and the title, which some may consider misleading regarding your actual issues with the new policy, is appropriate because 1) that's the feature as presented by Google, and 2) is clearly just the tip of the iceberg when you notice the post is quite long.
I made some subtle changes, mentioning that we're OK with planning ahead, and emphasizing that the lack of scheduled publishing is an even bigger problem.
I guess I could change the title? But I don't know what I'd change it to.
Release Scheduling is Impossible with Google's New Approval Process
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.
Started dipping my feet in app development recently. To get an app onto an Internal track for testing purposes..you still need to get 'reviewed'. literally a hello world app needs human review that takes 3 days. That blows my brain. Not open to the web. just testers. 3 days. painful. and imo. broken.
Luckily, you only need to get internal track approval the first time. After that, you can deploy changes to your own team with fast, automated review.
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")
There’s still a review process for the “internal” track even for an established app, and sometimes it gets held up. I think “internal” is a misnomer, it doesn’t seem to be handled any differently from a closed alpha channel.
This shouldn't make things harder for marketing. Have plans drafted and set dates after approval.
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.
What if there is a security update? I mean it sounds like this only applies to new apps, but if this gets extended to updates, you could have vulnerabilities out in the wild pending review.
Exactly. Hit this issue this week. I pushed out a change that had a bug, and the fix took 3 days... spent those days learning how to to do out of band updates from our own server in case hot fixes are needed.
If Google are _really_ reviewing the apps, creating a 3-day backlog to get approved, then I say "Bravo! The world could absolutely use less crapware on the Google Play store." But, the cynic in me tells me this is just a ploy by them to put on a masquerade of actually caring.
Yeah this seems strange. How could they go from no reviews whatsoever to being so efficient they can review all app submissions in just 3 days. The Play Store gets more app submissions per day today than the App Store did back when it took Apple weeks to review each submission. Google doesn't even provide human customer service for most of their products, so how are they suddenly so efficient at this?
They could start by automatically accepting apps they haven't gotten around to after 3 days of being in-queue. After some period of practice and improvements, if the team they prepared still can't handle the workload without the automatic acceptance fallback, then they can increase the team size. I'm just guessing a plan like that is doable.
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.
The real reason behind this will be automated generation of spammy apps.
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...
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.
There is no three day approval process needed for me to install software on my desktop. By going this way, Google is taking Android further and further from a general purpose pocket computer. I expect this move will quiet some squeaky wheels, but it also further opens up the market place for general purpose pocket computers like the forthcoming librem 5.
You can't install iPhone apps from outside the App Store on an iPhone (unless it's rooted, which most people prefer not to do for reasons of complexity and security).
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.
I'm surprised Google didn't pull the ability to download an APK and install it from Android Q. They modified the permissions slightly so now you have to click "allow" again every time an app wants to install an APK it has downloaded. Up until Q, once you used an app to e.g. update itself, it maintained the ability to download and install updates forever.
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%.
With this 3 day wait, you bet your bottom I'm going to have a release channel outside the play store. I can't do hot fixes of issues anymore. All bugs will take 3 additional days to be fixed now.
Actually, there is a 7 day timeout package updates for stable Fedora releases need to pass, unless they get testing feedback from the community. And even if they get feedback, It usually takes a couple days from the update being submitted and hitting the stable repositories.
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.
Mozilla has also recently introduced a 24-hour timeout for new extension submissions to AMO without telling anyone. (I only heard about it after filing a complaint to AMO moderators after my addon has been queued for almost a day.)
What's particularly annoying about the AMO case is that you can't even sideload addons on Firefox but that's a different issue.
As far as I know you can't install addons not signed by Mozilla in official Firefox builds. (Though I also haven't been able to get it working in my unofficial build.)
Well this might stop some malware, but what stops to push app with some kind of VM(or browser view) that load remote code and later update it to something else?
What they really need to address is hostile entities buying the rights to an app from the original developer and then using app updates to fill devices with malware.
Reviews aren't bad, but they don't necessarily stop bad apps, and they slow down good ones.
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.
It’s really annoying, we have an app that fixes a really big problem in Mexico, it’s been doing great on Apple Store, and android users are breathing on our neck waiting for the release, sore but I disagree, I don’t think that Google taking more than 3 days is going to benefit anyone. Shorter review process increases availability an that raises the playing feel. From where I stand, Google is just taking more time to review the apps, not necessarily improving the way they do it. Longer review times encourage more feature pack pack updates with more bugs, and linger time for users to get bug fixes...
I think both Apple and Google should make reviews optional.
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 entire point of the app store is to further concentrate power with Apple.
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.)
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.
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.
It does include a different sort of review system though. Every app is built from source by the F-Droid maintainers and has a corresponding source code bundle availabile. This means that if you notice or suspect any shady behavior, you can review the code to find out the exact nature of the shadiness and alert people. Developers can't as easily claim that it was an unintentional bug that happened to accidentally siphon all private data from your device.
After dealing with Apple's process, no one EVER said we need more of that! Among other things, the ease of approval is waht makes Android more loved by many devs, please don't spoil that
Yes it sucks for developers. Especially as others have pointed out because of the lack of an ability to submit the app early to have it reviewed and release at a later time.
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.
Oh what a beautiful lie. "If only Google blocked devs more, we'd all live in security Utopia".
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
Yes, malicious actors tend to use the same infrastructure as everyone else, especially if it is good.
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.
I had heard/read horror stories of Apple's approval process, so I was expecting a terrible experience. I had exactly the opposite; it was very smooth and much faster than I expected. (I don't recall the exact latency, but I seem to recall it was the next day.)
this is like a kid waiting until 11:59 Pm to submit his homeowrk, and then blaming the professor when the upload process takes 5 mins and his submission is late.
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.
OP here. Google offers no way to submit an app for approval in advance. You can upload a build as early as you like, but they won't start reviewing it until you try to go live. Then the app will go live immediately after approval.
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.
I know it's definitely a hotfix solution until Google fixes things, but would a soft-launch followed by a properly timed launch a few weeks later be better?
I mean, that’s sort of what we’ve been doing. (Hi, OP’s coworker here.) We’re a bit unusual in that we release games on Thursdays. In our busy season, that can be every other Thursday, with an email and social blast accompanying it. In the past we’ve submitted and been approved on Wednesdays so our customers know they can often sneak in Wednesday night and find our release before the marketing blast. In future, our soft launch will be two days or more, I guess, but we will submit according to that three day buffer. It’s totally doable. The problem is we can’t market a new game until it’s available on all platforms, which we time on each platform to the day. Ie we know how long ahead of time for iOS and Steam, and we (until now) also knew when to submit for Google.
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.
I haven't heard of doing 0-region releases, but 1-region soft launches are common - e.g. soft launching in a smaller, possibly english speaking country like New Zeland - fixing and tweaking based on the feedback and data you get from that - before hard launching with the marketing push to the wider world.
> If your app needs to launch on a specific day (it doesnt)
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.
>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.
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.
Little by little Google seems to be adopting all the policies for Android that made the iPhone simply a higher quality experience.
(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
The flip side of the same coin is that they’re dropping things that made life easier for developers -- Play Store reviews now take much longer, debugging gets harder with every OS update, etc.
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.
Inspecting network activity is more fiddly now -- HTTP is blocked and installing certificates for a proxy to intercept HTTPS is difficult. File system access is locked down. I’ve also been finding that the debugger just runs very slowly on an Android 9 test device; seems to be something to do with code verification.
Nothing insurmountable, just slower and more awkward than it used to be.
My guess is that this is what Google really wants. Now that all the hobbysists have helped get Android/Play Store where it is today, they don't need us any more.
Or, what if it worked in the other direction? What if a developer could buy an insurance policy from Google for a reasonable premium?
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"
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.