>That must be the most frustrating/annoying thing in the world.

Yes, and sometimes it gets even more frustrating when you get rejected for some minor issue like "the app name in the help menu is mis-spelled". An issue that takes you 3 minutes to fix and re-upload. And then you need to wait another 7 days. (If you're unlucky they find something else for 7 days more of waiting time).

If they're doing that level of scrutiny a million times, they should have released a tool (or even built it into Xcode); something like "Consistency Checker".

It's silly of them to reject apps entirely over checks that anyone could do in advance, if only they knew what to look for.

Not only would it be nice, but if such an application exists internally at Apple, and they released it with Xcode or something, then perhaps developers could integrate it into their testing infrastructure. If that chain of events happened, then it could bring up the consistency of Apple-centric OS 3rd party software, all the while decreasing time that updates spend in review. This sort of change could be a huge win for Apple, iOS/OSX Developers, and iOS/OSX users.

There are a lot of automated tests that the upload program and receiving web service already do. But "quality checking" is left up to a human editor.

Oh, they have ; but it doesn't do that many checks.

+ having a China wall between review (that are on the app store) and the support (that you may implement in your app if you wish) isn't so great.

When selling on Amazon for example, you have a ready to use support platform that allow you to easily interact with customers that seem to be strugling. I feel this really helps avoiding unnecessary frustrations.

Also, the best moment to collect feedback is when people are in review mode. And when your users get in review mode, they got straight to the app store where you can't reach them.

The intention of most of their decisions is more about their own money...

Case in point, it took forever for chrome or opera to come to iOS because they "competed" with the apple product already integrated into the OS, and "provided a less seamless user experience" ... basically, Apple didn't want to be outshined on their own platform...

I'm not sure who you're quoting with those quote marks. It's not Apple though, because I don't believe they ever said any such thing.

The reason Apple has always given is security. This is the reason they gave for not allowing third party access to the JIT version of the javascript engine. Their critics at the time claimed this was really because they didn't want other browsers competing with Safari, and they'd never let anyone have it because of that. Then when Apple developed the XPC framework allowing secure remote execution, they opened up the JIT engine to third party browsers in a secure way.

So far Apple's actual behaviour has been completely consistent with their stated reasons, which are not the reasons you are 'quoting' from somewhere, and in several respect contrary to the predictions of their critics. Isn't it possible that they are being honest about their motives?

But on the other hand, yes, the Mac App Store is a broken mess. Right now it's part of the problem with app distribution on the desktop, not part of the solution.

> The reason Apple has always given is security. This is the reason they gave for not allowing third party access to the JIT version of the javascript engine.

This doesn't make sense. You could disable the JIT, compile WebKit to native code, and ship it on iOS without the app requiring any more technical permissions. Apple just doesn't want you to do that for business reasons.

If you want to maintain that it's a security measure, there should be a specific attack concept you can describe that preventing alternative browser engines (suitably modified to work with W^X) stops.

Your comment doesn't make sense. You've always been able to embed the renderer with non-JIT JavaScript. Now you can build an app with full JIT embedded, so saying they don't want you to for business reasons is obviously false. They do let you do it.

The attack vector they're concerned about is to do with the JIT exposing access to shared memory. As for alternate engines, any such engine would need to include a JavaScript engine, which immediately opens up vectors for attack. That's why the ability to download and execute code is restricted. now, thanks to a robust and secure cross process communications framework, many restrictions that were supposedly 'for business reasons' have been lifted.

> Your comment doesn't make sense. You've always been able to embed the renderer with non-JIT JavaScript.

Apple's renderer. Not your own custom one.

> The attack vector they're concerned about is to do with the JIT exposing access to shared memory.

I don't know what "exposing access to shared memory" means. All applications that download data place potentially-hostile data into memory.

> As for alternate engines, any such engine would need to include a JavaScript engine, which immediately opens up vectors for attack.

Such as? Describe a specific attack that is prevented by forbidding interpreters of remote content.

> That's why the ability to download and execute code is restricted.

Downloading and interpreting code is something that even a PDF viewer does. Why is that not restricted?

> now, thanks to a robust and secure cross process communications framework, many restrictions that were supposedly 'for business reasons' have been lifted.

But not the restriction on alternate Web engines.

You're free to do exactly that. Nothing stops you from publishing a web browser that renders static HTML. But the only way to include a JS interpreter is to use the Apple-provided WebKit.

Language interpreters are forbidden to download any code from the internet, so you cannot use JS found on a web page in your own interpreter.

> Nothing stops you from publishing a web browser that renders static HTML.

That would not remotely be a practical Web browser in 2015.

> Language interpreters are forbidden to download any code from the internet, so you cannot use JS found on a web page in your own interpreter.

Which is a business decision.

I don't understand why this is controversial; it's well-established that many of the iOS restrictions are business-related. Note that I'm not even arguing here that those business-related restrictions are a bad thing.

That's not true. Apple allowed third party browsers - as long as they used WebKit - from day one when the app store opened.

Which makes them not really third party browsers anymore, they're basically frames around a UIWebView (which is Safari) which can't do anything interesting.

UIWebView and Safari are different things. Yes, Safari uses (essentially) UIWebView, but a browser is much more than its rendering engine.

The important bit there is "do anything interesting". Forget about any plugins that directly manipulate the markup (so no µ/adblock, no ghostery, no noscript).

Yeah, they can display web pages, but iOS Firefox/Chrome provide almost no benefits over the stock safari. Less in fact, since it's a near certainty that Safari is using privileged APIs to integrate with the OS in a way that no other browsers are allowed to.

(Didn't a very prominent company get sued for something along these lines back in the 90s?)

You can actually load whatever you want into a UIWebView. You could do the request, manipulate the response and display your modified HTML.

Adblocking is of course now integrated into the OS.