zlacker

[return to "Amazon has no idea how to run an app store"]
1. lkrubn+m1[view] [source] 2016-01-10 18:42:10
>>lkrubn+(OP)
This is perhaps the key bit of silliness:

"And this is where we run into the first bit of craziness. Amazon decided that they should model the Alexa app store after the iPhone app store. So there is a certification process to get your app into the store. But think about the difference: you are not uploading a binary file to the Alexa app store, you are simply registering an URL. So Amazon has no real control over your software. You could get an app approved, and then you could swap out the app for any other app, and the Certification team at Amazon would never know. They don’t control your code. Your code is not in their store, so they have no control over what you do. And yet they modeled this process after the iPhone store, where Apple does have control over your app."

But that doesn't get at how crazily broken the certification system. You have to read the quotes from the other developers to understand that.

◧◩
2. dperfe+44[view] [source] 2016-01-10 19:14:06
>>lkrubn+m1
Amazon has just as much reason as Apple (or any platform provider) to want to restrict the types of apps that get published.

As for the effectiveness of that control, there's little practical difference between "simply registering an URL" and uploading a binary; both can load external content or be modified (in terms of what the user actually sees/experiences) almost entirely after the initial review. There will always be apps that try to abuse that possibility, and they usually get reported or re-evaluated, but it's probably a very small number of apps that will do that.

The point is to simply filter out a larger number of spammy, malicious, or otherwise offensive apps at the onset rather than spending more resources constantly monitoring everything after the fact. That said, it's unfortunate when the review process is as flawed as it seems to be in this case (poor communication, inconsistent policies, etc).

◧◩◪
3. inflag+s5[view] [source] 2016-01-10 19:30:35
>>dperfe+44
There's a huge difference. An URL is an absolute black box, a binary that you have to give Apple for certification on each change and that has to call Apple APIs to do anything useful (like network) is not.

Apple will scan your App to check for basic violations, that's all automated. For instance is there a specific flag that you can initialize a socket with to listen in background. This is only allowed if your app is supposed to stream music in background or do some VoIP thing. So if you're app is not that and the software detects you have that flag set anywhere in the code no way you will get it through the certification. There's simply no possibility for such analysis with a URL.

◧◩◪◨
4. dperfe+t6[view] [source] 2016-01-10 19:44:05
>>inflag+s5
It sounds like you're assuming the majority of (iOS) App Store rejections deal with using unofficial/restricted APIs. My guess is that's relatively rare.

Most of the apps caught in the review process are probably those that fail other guidelines (usefulness, privacy concerns, illegal/inappropriate content, poor UX/quality, excessive crashing, etc). Most of those things can't be caught by automated means, and the content-related things can certainly be changed after initial review.

I've personally worked on several apps that significantly modify app behavior after being published - not so much to bypass any review requirements, but rather to adapt to changing business needs without waiting to publish a new release.

[go to top]