Hacker News Reader

Comment by kenjackson | Hacker News Reader

I disagree. Jobs wants to avoid overtly disgusting apps, like porn, but the App Store is littered with horrible user experiences.

The OP makes a valid point, which is that Apple does fear that the mobile space ends up being driven by a handful of third-party apps, rather than by the device/OS (and the AppStore is part of the OS).

So let me be clear. What is a killer app? A killer app is something that drives you to buy a device. The web browser is a killer app. Office was a killer app. Today there is no killer app IN the Apple App Store. The App Store is the killer app. And Apple controls it.

What Apple doesn't want is for Adobe or MS or Google or StartupX to create the killer app on the iPhone as they could diminish the importance of the iOS platform (since presumably this app will also shortly become available on other platforms).

View on HN

He doesn't actually care about porn; it's just an easily defensible position upon which to base controls over a wide variety of apps that harbor even the most tangential possibility to be used to view any pornographic content.

Of course there are some low-quality apps on the App Store, but what do people seriously expect Apple to do? Start rejecting Apps because some reviewer doesn't like it? That is the mother of all 'uncertainty' scenarios that undermine developer confidence (much more serious than the smaller risk that your App is blocked for breaching some obscure/vague part of the licence).

The only thing Apple can realistically do to affect the general quality levels is make broad decisions like no porn, no Flash, no technology X, Y, or Z.

Yes, Apple could have a cleaner process. Here's an example:

1) First submit application spec. The spec must get approved. That way you know the basic idea is fine. 2) Have a clear set of requirements -- largely automatable. MS does this for logo requirements and for the consoles. Devs can test against this even before submitting. This would be things like battery consumption, CPU utilization, stress, etc... 3) Apple has discretion to block apps for extenuating circumstances -- this should be rare, like an App not implementing the spec at all.

This would lead to even greater quality, decreased uncertainty, and increased transparency.

Your kidding right? No company in their right mind is going to submit an application spec for their app to Apple before they have a releasable app. You don't give your unique product/idea away to someone with a vested interest in perhaps beating you to the punch with it. If Apple wasn't in the Mobile Apps business it might fly but they are in that business and giving them an application spec really wouldn't be wise.

Ideas are worthless. It's execution that counts. Examples of "ideas" that were won by the best execution include:

Google (search)

Facebook (social network)

Microsoft Word (word processing)

Photoshop (image manipulation)

iPod (mp3 players)

iPhone (smartphones)

Each of these "ideas" had competitors in the market before them, and each managed to blow the competition away by better execution. This is the reasoning behind VCs not signing NDAs, and entrepreneurs accepting this.

A spec is more than an Idea though It's the plan for your execution. Otherwise it's useless for Apple.

No, I'm not kidding. This is largely what goes on with consoles today anyways.

But in any case, this is Apple's appstore, you have to go through them anyways. If Apple wants to steal your idea, what is to stop them from stealing it after you've written it and submit it.

In fact, its even worse the way it is today, because they can hold on to your app for months before approving/denying it. And then they can reject it, and then the next day release their application, which they built from reverse-engineering your application.

At least with the spec, you describe the user scenario, but they'd still have to figure out how to implement it.

But lets be clear, in any case where Apple owns the key to app store entry you're vulnerable to them stealing your ideas or even implementation.

It's less absurd than rejecting apps because of the language they were "originally written in," less absurd than rejecting minor updates to an app you've already approved — less absurd than most of Apple's rejections, actually, because at least then Apple's rationale would make sense without assuming Apple is simply evil.

What? How is rejecting apps/updates for technical infractions (cross-compiled code) absurd? Undesirable for the developer perhaps, but nothing compared to the worry that someone's general opinion of your individual app could kill the whole project. The rationale is also pretty much irrelevant if the rule is already published (eg. no cross-compiled code) - you don't need to second-guess it, you just need to follow it

If you sketch out pseudocode on a napkin or use an algorithm you learned about in Python, you are technically using something that wasn't originally written in Objective-C and are back to hoping the App Store reviewers exercise the rules with sanity. Compilation is just transforming data from a less useful form into a more useful one. That's why it's absurd.

But why pretend that this would actually happen? Compilation is transforming programming language into machine code; writing in this case is the act of typing out your program in programming language. 'Originally written in Obj-C' means the code was formed by you in Objective-C before being transformed by a compiler. It is now machine-code, it was 'originally,' ie. before compilation, Obj-C.

They care not a jot whether your adopting code from a Python project. Technically it's not the same program then anyway. Everyone knows this! C'mon

Reply on news.ycombinator.com