Hacker News Reader

Comment by archgrove | Hacker News Reader

Genuine question: How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3? For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code). However, Microsoft/Sony/Nintendo still seem to be allowed to place pretty heavy licensing requirements on game publishers (so strict you can't actually know them without handing over a lot of cash).

I tend to agree with antitrust action most of the time, but it seems that platform owners should be able to have some say over their platform direction, if they honestly think that doing so is good for their business. Whilst they don't have a monopoly in the market, and there is plenty of choice for consumers, what benefit does the public get from forcing people trying the "Closed is better" business model to open up to direct competitors (who, depending on what you believe, might seriously damage the experience for end users)? If the market dislikes the closed system, it will fail. If it grows to be dominant, then sure - anti-trust seems reasonable. But whilst competition is thriving, it seems heavy handed to rule out certain business models.

View on HN

Exercising control over a given market ("video games for Xbox" or "software for iPhones") in which you have a monopoly is not illegal, it's when you use your monopoly to push out competitors in different markets (such as "development tools" or "mobile advertising") that the Sherman Act prohibitions on illegal tying apply.

In Eastman Kodak Co. v. Image Technical Services, Inc., the Supreme Court ruled that Kodak had a monopoly on replacement parts for Kodak copiers, and by refusing access to parts and manuals to their competitors, they were illegally tying their parts monopoly to the market for repair service. The Court wrote: "power gained through some natural and legal advantage such as a patent, copyright, or business acumen can give rise to liability if a seller exploits his dominant position in one market to expand his empire into the next" (504 U.S. 451, 480 n.29 (1992)).

In the case of video game makers, you may have a case if e.g. Microsoft took active steps to prevent someone like EA from creating their own version of Xbox Live (since the market for games is different than the market for online services), but I don't believe that's the case.

Seems to me there is a big difference between 3.3.1 and the Kodak case. Apple says "this is what you have to do to be in our store," which is very different than refusing to sell people proprietary parts.

Is it anti-competitive if Wal-Mart refuses to stock goods from a vendor who doesn't meet their quality requirements? If it were, all businesses would go out of business.

Apple isn't competing with Adobe. They are saying that they have quality standards for the ways apps are made.

It's as if Wal-Mart said to their (potential) vendors: Company X's factory equipment does not meet our quality standards. We refuse to stock goods made with Company X's factory equipment. So if you use Company X's factory equipment, we will not stock your goods.

This is hypothetical, but Wal-Mart does use its extreme leverage to get conformity of all sorts out of its supplies, including (believe it or not) by eliminating questionable agricultural production processes.

And, so far as I know, nobody has ever screamed monopoly about that.

By comparison, Apple does not keep the parts (XCode) or the instruction manuals (documentation) from their competitors. They are not withholding secrets. They do not lock them out of developing for the platform in compliant ways; they do not block them from cross-compiling to cacheable web app that can also be placed on the iPhone "desktop"; they do not stop them from loading their non-compliant apps directly, outside of the store.

They just will not stock their goods, in their store.

Now. Are there precedents of desirable retail stores being forced to carry products they don't want to?

> Wal-Mart refuses to stock goods from a vendor who doesn't meet their quality requirements

Well, that's just the point. Apple doesn't care about the quality of the application. They already have a screen for that by virtue of their control of the app store. They are refusing apps based on the technology that was used to create them. It could be the most beautiful, performant, amazing application ever written and their developer agreement rules it out.

Yes, exactly. It's really not much different than an employer trying to maintain the highest quality employees by using race as a hiring decision.

Apple already has an extensive quality control process for iPhone apps. If they can't come up with objective criteria that they can test apps against in the approval process then they shouldn't just use prejudicial BS to try to filter out so-called low quality apps. It's anti-competitive and anti-innovative. It's nothing more than a big company throwing around its weight trying to be a bully.

Except that Apple owns a monopoly on iPhone application distribution. Just as in the Kodak case where Kodak had a monopoly on parts.

In the Wal-Mart case you can hardly argue that Wal-Mart owns a monopoly on consumer good distribution.

The key thing here is that there is no way to get a legitimate application (and web-apps hardly need apply) onto the iPhone without going through the Apple channel. It looks and smells like a monpoly (at least as defined in previous supreme court rulings) to me.

Let's compare…

Kodak wouldn't sell parts to other parties.

Apple won't sell your stuff in their store.

There's a pretty clear difference here.

Imagine if WalMart required vegetable growers to use WalMart brand fertilizer if they wanted their vegetables sold at WalMart. That seems a bit more like the current situation with Apple. It's not at all apparent that there was a quality issue with apps not programmed in Objective-C, and it's certainly not obvious to me (as an ex-Apple employee, Objective-C-coding, iPhone and iPad developer) that Apple would be able to prove in court that the license agreement is about quality rather than competitive interests.

There are in fact technical reasons why XNA games need to run on the CLR. The XNA CLR stack implements aspects of the security model.

The fact that the 360 itself can run "native" code (in fact: hardware-managed code running in a VM) is irrelevant; Microsoft has onerous licensing and contractual agreements with the people they allow to write native games. On the other hand, anyone can write an XNA game.

In point of fact, XNA is more burdensome on X360 developers than "3.3.1" is on iPhone developers. For the most part, iPhone devs are on a somewhat level playing field with Apple (there are clearly exceptions, but the showcase apps on the iPhone tend to come from third parties). Apple's restrictions lock developers into 95% of the same platform as Apple itself uses. XNA is a second-class citizen on the XBox 360. Microsoft does not allow random people to write full native Xbox titles.

I believe that's pretty much exactly what I said.

I'm confused, Dennis. Was I replying to you? Also, it looks like we're saying the exact opposite thing.

Sorry I didn't read the thread correctly and mistook the placement of your reply.

However yes my statement was very much the same, however questionable comparisons to the console market may be.

The comparisons seem especially apt.

Microsoft: Nobody can develop first-class applications for the platform without licensing the (extremely expensive) X360 XDK, which includes an approved compiler toolchain.

Apple: Anyone running OSX can develop first-class applications for the platform using Xcode for a (very cheap) developer fee.

XNA is a red herring. It's (to use MSFT's term) a hobbyist platform.

The main way they're different is that people have always expected consoles to be walled gardens. They have expected the same things of phones, but because the developer of this phone is Apple, they thought that the model would be more similar to the way desktop applications are developed. The only significant difference is one of expectations.

But "I expected it to be different" doesn't seem like a sound legal foundation for anti-trust action. In many ways, the iPhone has been the founding of "open" phone development. Prior to the iPhone, there was virtually no real development allowed on phones that achieved any levels of success (carriers had the platform locked down hard). Post iPhone, we've seen actual competition in this space - the entirely open Android strategy (though their App Store also has restrictions, they just apply them post-release rather than pre-release); the semi-closed iPhone and Nokia Ovi models, the web app model of all the platforms. People claiming that Apple has created a locked-down environment have very short memories - even the closed nature of the App Store via 3.3.1 would have been considered insanely open only 5 years ago.

Google have bet that unfettered platform mutability with (almost) totally free development is good for their business model. Great, and more power to them. Apple have bet that allowing a freeforall would cause their business model damage; OK, that's their call. Other platform holders are trying other strategies. The point being, the free market seems to be about allowing them to try these ideas, and fail if consumers don't like them. Whilst Apple are nowhere near a monopoly on smartphones (and they're frankly miles away from one), they should be free to adopt whatever model they think works best for them.

> doesn't seem like a sound legal foundation for anti-trust action . . .

Don't get me wrong. I'm right with you there.

>> Prior to the iPhone, there was virtually no real development allowed on phones that achieved any levels of success (carriers had the platform locked down hard).

cough The development for mobile phones partially sucked (and still does, partially; it's in the nature of the beast I suppose, for now) before the iPhone, but I don't know about it being not allowed. You have to draw a distinction between so called feature-phones and smart-phones here. Feature-phone dev was and still is largely restricted (not to mention uninteresting from most POVs) but the same cannot be said about smart-phones. Seeing how the iPhone is supposed the be a smart-phone, we should compare it to those I think. And to that end, I seem to remember writing mobile apps for Windows Mobile and Symbian long before the iPhone existed. Some of that writing didn't even suck that much and I definitely didn't have to ask nobody's permission to distribute the apps. Python for S60 [1] appeared before the iPhone not to mention the c/c++ based toolchains from MS and others. Even the appstore concept is not really Apple's invention, Handango predates it by quite some margin for example.

>> In many ways, the iPhone has been the founding of "open" phone development

I don't know in how many were those ways. I would say it made it's (phone development) products cool (albeit not yet mainstream) for the masses, and that is very nice and respectable, but "founding" and "inventing" and "reinventing" are just hyperbole filled, marketing words that Apple touts around.

>> Post iPhone, we've seen actual competition in this space - the entirely open Android strategy (though their App Store also has restrictions, they just apply them post-release rather than pre-release); the semi-closed iPhone and Nokia Ovi models, the web app model of all the platforms.

A few lines up, you were talking about "phone development" and I assumed you were referring to application development because you mentioned carriers platform locks. Now you refer to appstores. Not the same thing. And even there, there was competition [2].

>> People claiming that Apple has created a locked-down environment have very short memories

I would argue that it's somebody else exhibiting short memory here but I have already.

>> even the closed nature of the App Store via 3.3.1 would have been considered insanely open only 5 years ago. No... it would not have been. Again, please see [2].

The thing is, we had "open for development" smart phones before the iPhone. The platforms were less cool. Some of today's platforms, that are still more "open for development" are more cool in at least some ways that the iPhone.

[1]: http://en.wikipedia.org/wiki/Python_for_S60 [2]: http://en.wikipedia.org/wiki/List_of_digital_distribution_pl...

Your entire response seems to have missed my "allowed on phones that achieved any levels of success" qualifier. Name me any pre-iPhone development platform allowing development that had ever created a truly viable marketplace. There were a few faltering attempts with Windows Mobile and Symbian, but frankly, they were terrible. And yes, I am conflating development and the distribution channel, but this seems fine to me - if you develop, and noone ever runs it, did you develop anything?

Having seen [2], I think my point is even stronger - first class smartphone development really began with the iPhone (the App Store predates any other competitor). Of the third party services, only 4 predate the iPhone by more than a month or two (and of those, only 2 achieved even the level of success needed for a Wikipedia page).

"There were a few faltering attempts with Windows Mobile and Symbian, but frankly, they were terrible."

Technology marches forward. My N1 has more power than my desktop did just a few short years ago.

Prior initiatives died primarily because of technology limits that made the real usability of apps incredibly limited.

> There were a few faltering attempts with Windows Mobile

In 2003 I had a iPaq PDA with Pocket PC 2002. It had a marketplace ... some of my apps where sold by the local HP distributer and I was quite happy ;)

These devices where not mainstream because of poor hardware capabilities, and because of the lack of public Wifi / 3G networks, but still I was amazed by how much it can help me organize.

Apple makes cool products and its timing was perfect. That's about it.

Since in your eyes the iPhone is the _first_ smart phone that qualifies for "any levels of success" it is of course the most open.

I think several smart phones were successful (at least in europe) and had a more open development environment. You could install unapproved apps (up to S60 2nd ed. After that some APIs were restricted for unsigned apps. But even then you could buy those certificates). There was no company I know of that disallowed satire or certain programming languages or interpreters on their phones.

Those phones were:

Sony Ericsson P800 (you could even run javac on it in) and its successors P900/P910

Several Nokia S60 phones before 3rd ed.

With limited APIs S60 3rd ed. like the Nokia E90 (my last phone before the arrival of Android phones)

>> Prior to the iPhone, there was virtually no real development allowed on phones that achieved any levels of success (carriers had the platform locked down hard).

Windows Mobile / Windows CE phones have been around for years. I still remember the joy of writing my first app in Visual Studio to run on my Samsung i700. Also I spent many hours playing Monopoly on that same phone.

AFAIK, console makers require developers to use their SDKs, but they don't care about what happens before that point in the pipeline. What Apple did was more like forcing 3D models to be created exclusively with Maya.

but they don't care about what happens before that point in the pipeline.

They most certainly do. The difference is in their point of control. Console makers exercise far more control over who is allowed to develop for their platform, and that control extends to who is allowed to develop middleware. They may or may not have restrictions on programming languages, but they do more generally exercise a degree of control over the tools you're allowed to use. It's difficult to know exactly what is and isn't allowed, as it's all under NDA, but there are certainly some shared motives.

The Xbox 360™ Tools and Middleware Program licenses professional developers of games software tools and games middleware applications to obtain full Xbox 360 Development Kits and to distribute Xbox 360 code to approved Xbox 360 developers and publishers. -- http://www.xbox.com/en-US/dev/tools.htm

3rd Party Tools, QA/Testing, and Localization companies can also apply for Authorized Status using the same Application. You will need to select the appropriate category from the drop-down box in the Application. -- http://www.warioworld.com/apply/

Under this license program, licensees will be entitled to 1) access to development environment and technical information of "PLAYSTATION®3" which is the same as development environment and technical information that licensed game title developers have access to, 2) develop tools and/or middleware to be used in the game title development for "PLAYSTATION®3", and 3) directly provide licensed game title developers with such tools and/or middleware. -- http://www.tmstation.scei.co.jp/ps3/info_e.html

>> but they don't care about what happens before that point in the pipeline.

> They most certainly do.

MS/Sony/Nintendo don't require licenses from all the middleware people. However, SOME of the middleware people will ostensibly want to test on the platform, so will buy the product from MS/Sony/Nintendo. If they do not wish to do so, they need not, then the end licensor of those third party toolkits/whatevers, can still use it.

What Apple is doing is 1 step more: They say you can ONLY use tools made in a certain way. MS/Sony/Nintendo do not limit that.

Apple's restrictions are above and beyond anything that any console maker requires. Requirements on the end product are to be expected, requirements on the specific tooling used to create the product are more unusual and potentially represent anti-competitive activity.

With respect to game consoles, Microsoft/Sony/Nintendo have their own acceptance processes, but they do not require you use a particular compiler or code in a particular language, all they care about is the end product. A lot of the multi-platform games these days are developed using tool-chains specially built for the purpose, so that, for example, the PS3 release and the 360 release are just different builds from the same code base rather than awkwardly separate development efforts as they would be otherwise. Such tools vastly ease the burden of releasing to multiple consoles and in many cases enable developers to do multi-platform releases that they would otherwise not have the resources to do.

Apple's licensing restrictions make this sort of thing impossible. You can't reasonably build a tool-chain to target, say, both iPhone and android development from the same code base. Not and live up to Apple's licensing restrictions.

And that's very much anti-competitive on Apple's part. It means that more and more people have to choose, have to be "locked in" to one particular platform.

does microsoft also prohibit 3rd parties from producing compatibility layers on top of .Net?

No, as far as I know, Microsoft does not contractually obligate developers to use their tools. The .NET CLI is an ECMA standard, and there have been a few alternative languages developed for it (same as the JVM). I'm not aware of anything that would stop you from writing an XNA game using Boo, for example.

The list of requirements is made available to the developer well in advance, it isn't arbitrarily made more restrictive by first parties (Sony, Nintendo, Microsoft), and every developer goes through the same submission screening process. If a game is rejected for not meeting the established criteria it happens before it has shipped -- titles aren't just pulled for no apparent reason.

You're missing the point. This is an anti-trust action. None of Microsoft, Sony or even Nintendo can be said to have the kind of dominant position in the console market that Apple does in smartphones. They're not a monopoly, but they're distressingly close. And they appear to be taking actions that can be pretty clearly seen as anticompetetive -- leveraging their dominance to make compatible applications for other platforms more expensive to develop.

So yeah, I think an inquiry is an appropriate course of action here, for the same reasons it was in the 90's with microsoft. If you "tend to agree with antitrust action most of the time", but not this time, I think you might be better served by introspection than posting a defense of Apple.

But they're nowhere near "distressingly close" to a monopoly - even picking the most Apple friendly metrics, they have only 25% of the smartphone market, with Android constantly closing the gap (and e.g. Blackberry actually ahead of them in some areas). The Wii, on the other hand, has around 50% of the current generation console market.

They seem to have a monopoly on marketplace hype, I won't doubt that. But to claim they've a monopoly on smartphones is just plain wrong.

The iPhone is the first, and in some cases still the only, platform to target if you're doing anything in the mobile consumer space. RIM competes with businesses only, there is no meaningful "app market" there, nor with Windows Mobile. Android is doing well, but it remains a distant second.

Wrong metric. You may as well choose "Shiny plastic devices market" as "smartphone market," because neither directly affects third-party devs. What matters here is app market, and Apple is utterly dominant there.

So Apple has a monopoly on the iPhone app store - no great surprise there. I may as well claim that Microsoft need to open the 360 marketplace to my personal ideals, because they have a monopoly on licensing XBox 360 games.

The Android app store certainly exists, and is doing quite well. The web is free for all platforms. Apple don't, by any realistic measure, have a monopoly on application sales for smartphones. They just couldn't - with only 25% of the smartphone market, and an app store that targets only that 25%, how can they have a monopoly on smartphone app publication? What they might have is a monopoly on the wealthy gadget consumer with large amounts of disposable income to spend on apps. I'm not, however, that Apple's clever demographic targeting, coupled with the inability of their competitors to eat into this market via fair competition, is reason to force them to change their business model.

Here's hard numbers: Apple was responsible for more than 99% of all mobile app sales last year. cite: http://arstechnica.com/apple/news/2010/01/apple-responsible-...

So I don't think we can say "they just couldn't" — in fact, they just did.

And I might be skeptical about the numbers (Gartner isn't infallible), but every story I've heard from cross-platform mobile dev houses agrees with this — you'll get almost 100 times the sales on iPhone that you will on other platforms. I've never heard a contradictory story either, not even from Google trying to puff itself up. That's pretty much a monopoly.

Wrong and wronger. Each of the console gaming companies you mentioned has more market share in consoles than Apple has in smart phones (and Apple's share of mobile phones as a whole is trivial). While the iPhone might garner 95% of Hacker News entries, it's only selling about 15% of smart phones. (That's a lot, especially at the markup Apple gets off of it, but it's less than any of the console makers has.)

Regardless, one does not need a monopoly to engage in anti-competitive actions and for them to be illegal.

I think the distinction that is confusing several people is that between the market for cellphones and the market for applications which run on high-end cellphones/mobiledevices. Using some of the numbers thrown around, it's the difference between saying Apple has only a 15% share of the cellphone market, vs., 99% share of the paid smartphone applications market. It's that latter market that Apple is clearly the dominant player in, and their change to the 3.3.1 could, by a reasonable person, by seen as a move to stifle development on competitive platforms. I think this is the basis for a potential investigation.

Maybe the issue is that in order to develop for the iphone or Ipad you are forced to use the SDK which in turn requires apple hardware (MAC) and apple software (OSX) to run. software that you are also prohibited from virtualizing?

The way I always thought Apple avoided Anti-trust is that it controls the entire stack from software to hardware. The fact that they let you develop any apps at all, for any of their platforms, is their choice which they should be able to deny at will. You as the consumer don't have to buy their things if you don't like their policies.

Contrast this with Windows on any number of manufacturers of PCs. Where Microsoft went wrong is that they said, "We'll give you OEM pricing if you agree to this, this, this and this. Otherwise we'll make it difficult for you to compete." It's that sort of bullying that's a problem, because they don't own the entire stack.

They avoided anti-trust because they have a single-digit percentage of the PC market. It seems their position with the iPhone in the smartphone market is much more dominant, though I don't know what the numbers are.

>How are the restrictions placed by Apple on what's allowed in the App Store any different then the restrictions placed by console owners on what's published for the XBox or PS3?

>For example, the XBox XNA community games system requires people to use .Net - there's no technical reason for this (the XBox is clearly capable of running native code)

XNA requires you to target the .NET runtime. It does not dictate what tools you use to generate the assemblies. If Microsoft had a clause saying that you had to use Visual Studio Ultimate on Windows 7, they would get demolished.

And you can target native, but you have to buy the expensive SDK and sign a revenue sharing agreement. That's the financial model behind consoles (where they are generally sold at a loss). Again, though, how you develop is not Microsoft's concern, and you have no limits on that, so long as you fall within the bounds of the runtime.

Apple's restrictions are not at all comparable.

If Apple implemented 3.3.1 as a clause that Apple will impose minimum quality levels, feature completeness (e.g. "you must use the current available features of the platform"), etc, that would be one thing and they would have been entirely within their rights to do that. That is not what they did, but instead they are saying that a super shitty, super inefficient crapshoot of an app that misuses and underuses the platform is okay, but one that is developed in a different manner is not just because.

The distinction Apple is making is thus:

A "bad" behavior written into an app by hand may break on a new update, but it affects only itself.

A "bad" behavior written into middleware may break on a new update, and may take out dozens, hundreds or perhaps thousands of apps.

No-one would expect Apple to take special pains to avoid breaking a handful of random apps in the app store. But if some middleware bug effected thousands of apps, they would.

To deny that is to refuse to learn from all the intentionally-protected bugs and legacy behaviors in modern desktop operating systems, that linger solely because the platform provider doesn't want to break large swaths of legacy apps.

This justification is one of the most astonishingly vapid ones around. I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on.

The distinction Apple is making is that they have a temporary mindspace monopoly of the smartphone markets and they want to cement it in by forcing developers to help the Apple cause.

> I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on.

So you've never encountered a standard/API/platform that perpetuates bugs, support for bad practices or misuse of old interfaces to avoid breaking legacy apps?

Good platforms get updated instantly and aren't using too many unofficial APIs. If something so awful happens on an upgrade that it breaks such a middle layer, it will also break many native apps which will also need upgrades.

Also, applications written for cross-platform development tools are higher-level and for complying with any new interfaces you may have it's just a matter of rewriting some bindings. In case the change is so radical that it needs architectural changes (like from Carbon to Cocoa), you can always force tool vendors to update their platforms by pulling out Carbon completely (how could they do that if some of their own apps are still on Carbon?)

In fact I would bet that applications on stuff like MonoTouch would've gotten upgraded from Carbon to Cocoa a lot faster than native apps were.

Really, you're setting up a strawman argument.

It's hardly a strawman. The history of personal computing is littered with examples of this, many of which have been covered ad nauseum during this 3.3.1 debate.

Your argument, in contrast, is alternately "that doesn't/won't happen" or "that's no big deal". Which is an assertion that stands against the piles of evidence that it does and is, and an assertion you don't back up at all. Why should middle-ware be different this time?

For the record, I don't think middle-ware decay is a reasonable argument for Apple disallowing it. (I do think it's the argument against developers relying on it.)

I'm just getting rather tired of people either misrepresenting or ignoring the other side of an argument. There's plenty there to disagree with. It makes no sense to pretend that middle-ware decay doesn't or --for unspecified reasons-- simply won't happen this time.

All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Adobe's delay in switching to the more modern APIs is the reason why they couldn't ship a 64-bit Photoshop for Mac until now.

As Jobs has explained, they've been burned before.

>All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs.

Humorous given that Apple has several very prominent apps (iTunes, Final Cut Pro) that still have made the migration. And they control both sides!

However that is irrelevant. Tell me again how, if Apple revises the API, that suddenly every app available will instantly morph to accommodate it? Of course that is completely and utterly asinine. It's a ridiculous argument that I can't believe knowledgeable people have, desperately trying to reach some sort of rationalization of Apple's actions.

To put it even more starkly, if Apple were to revise the API, then the middleware pushes an update, and all those hundreds or thousand of app developers simply recompile with the new OS target. All of their apps are now feature-compatible with Shiny New Feature X, rather than those hundreds or thousands of developers all having to replicate the same work. This is Frameworks 101.

The entire point of an abstraction layer is to isolate a developer away from the underlying systems, to let him write more business logic and less systems support code. All modern software development is built on the concept of frameworks, layers of abstraction, and the like. Even Objective C itself is an abstraction away from the ARM11 instruction set on the iPhone's CPU. Do developers writing Objective C produce inherently inferior apps to those writing ARM11 assembly?

Frameworks reduce the total number of man-hours required to produce and maintain software. I will argue that a good framework produces more high quality software than a bunch of developers all rolling apps on the metal, which then have a longer lifetime, due to the fact that fewer developer hours are required per app to maintain it moving forward. (Please note that I am not making any kind of judgment here about whether or not CS5 constitutes a "good framework".)

It takes some pretty serious denial to see Jobs' case against middleware, cross-compilers, and abstraction layers as anything but an attempt to lock developers solely into the Apple ecosystem. Frameworks reduce developer hours in more than one way - they reduce the number of hours required to put your app on multiple platforms. (To put it another way, this is why we have 3D engines like Unreal and Crytek; it's why we have 3D API layers like OpenGL and DirectX. You can write a game without them, but you'll spend thousands of hours solving problems that have already been solved for no appreciable benefit.) It's abundantly clear that there is no real technical justification for the clause; Apple is attempting to increase the amount of work that developers have to do to target multiple platforms, so that they'll simply give up and pick one: Apple's.

Could you stop using words like "vapid", "ridiculous", and "asinine"?

Developers who build on Flash can't multitask until the iPhone Flash runtime exposes the multitasking API. The developers of those applications are beholden to Adobe to get access to a core iPhone OS feature. This is not a complicated argument.

Reasonable people can disagree about whether this is a valid reason to lock down the compiler toolchain for the OS. But I don't think a reasonable person can pretend that there's no opposing argument, no matter where they start from.

>Could you stop using words like "vapid", "ridiculous", and "asinine"?

No. It is what it is. You don't like it because it undermines your blatant, translucent apologism.

>Developers who build on Flash can't multitask until the iPhone Flash runtime exposes the multitasking API.

The sort of apps built with Flash are unlikely to be the sort that would need to access the multitasking API. That's a specious, ridiculous example. Your example is as logical as Microsoft banning any language but C# from ASP.NET because hypothetically it will be the first to take advantage of a new IIS feature. Thankfully most people realize how damaging and absurd such an argument is.

>The developers of those applications are beholden to Adobe to get access to a core iPhone OS feature.

NO THEY ARE NOT

See, they have the choice whether to use the toolkit or not. If it doesn't stay current, and their apps aren't as saleable because they don't take advantage of the latest innovation or use the latest instruction set or yield the best performance, developers migrate away. That's how "free markets" work.

Apple completely undermined that, yet remarkable the faithful go forth to sell the pitch despite having a complete absence of empirical standing for it.

>This is not a complicated argument.

Right. It isn't.

Honestly I'm surprised I haven't been moderated to -infinity, as Hacker News is generally a clearinghouse of pro-Apple apologism. If this place is starting to get more centrist, Apple really is in trouble (PG already alluded to this a couple of essays ago)

> The sort of apps built with Flash are unlikely to be the sort that would need to access the multitasking API.

The sort of apps built with the iPhone SDK are unlikely to be the sort that would need to access the Flash runtime.

> See, they have the choice whether to use the toolkit or not.

See, developers have the choice whether to distribute apps via the app store or not. There's always the web.

See how that works?

Yes, I see that you have absolutely no comprehension of choice.

The problem I see is that Apple feels poor apps (whatever that means) reflect poorly on it rather than just on the app makers themselves. This is new. On OS X a crappy app is just a crappy app. Nobody blames Apple, people blame the application developer. There has to be some argument made that on a small mobile device this distinction is warranted, but I haven't heard it yet.

Actually, it isn't a new behavior. Look at the history of Nintendo and the Atari 2600. Bad apps reflect on Apple, just as bad games reflected on Atari.

I meant it's new for Apple in relation to, say, OS X.

Despite all the Adobe advocacy, people blame Safari and Apple for crashing when the trace shows it was the Flash plugin. Most people don't know what did it and blame Apple. I think they are tired of it.

Wouldn't that apply to C/C++/Objective C libraries as well? Let's say everybody is using some popular Objective C library from github and it has a bug with a new iPhone OS. Apple would then be in a position of getting that library patched and getting potentially hundreds of apps to update to the latest version of the library.

Should Apple outlaw 3rd-party Objective C libraries as well?

The key difference is that if the bug is in your own code, you can fix it. This could be trivial or it could not be, but it's within your sphere of control. If the bug were in (say) Adobe's code, you could not, nor could Apple.

Fun excuse, but section 3.3.1 forbids even intermediary translation or compatibility layers under your control. So that's a line of bullshit.

I said nothing about "intermediary translation or compatibility layers", nor did the post I was replying to. Please read the thread for context before posting.

"[I]ntermediary translation or compatibility layers" is directly from section 3.3.1 and the entire reason this thread exists. Please read the primary sources for context before condescending.

The specifics are different, no doubt - but the ethos is the same. Microsoft force you to use .Net (of some form) and their APIs because that fits their business model (i.e. ties you to the XBox). They're restricting me from using my platform portable pure C code, which is their choice. I obviously don't know, but suspect if large amounts of code started targeting XNA in a cross platform way, they'd come down on that too. I also don't know what the requirements of their commercial licence are (and unless you're an XBox developer, neither do you), but it's almost certainly more than just revenue sharing (they would never allow the publication of a "Crash a plane into the twin towers" game, for example). Moreover, I do know that Nintendo certain did (and I think still do) have strict policies on types of violence in games for their platforms.

Regardless, the general point stands. They're making choices based on what they think is best for their platform, and letting the market chose. This is how the free market is supposed to work. It breaks down when there are entrenched monopolies, or when other external factors prevent people from exercising their right to buy an alternative, or start a competitor - but that is demonstrably not the case here. So why not let the market decide?

"They're making choices based on what they think is best for their platform, and letting the market chose."

The former is absolutely true. The latter is absolutely not. Hence why the government is looking into it.

Apple's actions are completely inexcusable and borderline illegal. It is only by incredible bravado and arrogance that they could have ever thought that 3.3.1 would be acceptable. They could have accomplished the same goal more subtly, but, probably due to Jobs universe-sized ego, they had to bring this upon themselves.

"This is how the free market is supposed to work."

No, it isn't at all how the free market is supposed to work. 3.3.1 is the exact opposite of a free market.

You're missing the bit where Apple isn't by any means the only phone manufacturer around.

And you're missing the part where they're a $250 billion dollar company.

This has nothing to do with being a monopoly. When big companies do shitty things to undermine normal competitive forces they get scrutiny.

See the Eastman Kodak case: http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=US...

How are Apple preventing you from buying the ever more popular Android phones? Or Web OS phones? You, a member of the market, buy the phone with the features you want. If you don't like Apple products, or the app store they provide, buy one of the many hundreds of alternative smartphones, many of which have large adoption.

"How are Apple preventing you from buying the ever more popular Android phones?"

They aren't and I have. Right now, however, the biggest momentum that the iP(hone|ad) has is the app market, and the fact that a lot of large organizations have special support for its walled garden. 3.3.1 is Apple's way of trying to ensure that it is a specially cultivated walled garden, and that it's more likely that "there's an app for that" only applies to the Apple devices.

I think it's a futile move that is too late, but that is the clearly obvious motive behind 3.3.1. It is anti-competitive and without justification, and honestly it's a bit bizarre that so many fail to grasp that.

it's a bit bizarre that so many fail to grasp that

Have you considered the possibility that it is not so clear and obvious as you think?

>They're restricting me from using my platform portable pure C code, which is their choice.

Couldn't you just use managed C++?

Microsoft force you to use .Net (of some form) and their APIs because that fits their business model (i.e. ties you to the XBox). They're restricting me from using my platform portable pure C code, which is their choice.

You're missing the point. Microsoft makes it technically difficult to write a game in a non-.net language, but (at least as far as anyone knows) it's not disallowed in their developer agreement. If you can get LLVM to spit out .net bytecode that works, then good on you, there's nothing keeping you from using it. There's no clause that prevents you from writing a Lisp interpreter in your game, nothing to keep you from auto-generating C# from template files, etc. The only reason people don't do these things is that they're a pain in the ass, not that they would be in violation of the developer's agreements that they signed.

Certainly attempting to achieve developer lock-in is part of good business, especially in the world of game development. But make no mistake, Apple is in uncharted territory here: rather than trying to get people locked-in by providing a smoother workflow with their toolset than they'd find elsewhere (which is what Microsoft does with .NET), they're declaring that all other tools, better or worse, are strictly prohibited.

They're making choices based on what they think is best for their platform, and letting the market chose. This is how the free market is supposed to work.

Bundling IE with Windows without any option to replace the browser is what would be best for the Windows platform. A "plato o plomo" acquisition/sued-to-death strategy employed by would-be-monopolists to kill off competition before it's big enough to compete is best for the business. Gauging prices in a market where a near monopoly exists is "best for the platform."

What you're really hinting at is a discomfort with the entire idea of anti-trust legislation, another discussion altogether. Suffice it to say that "let the market decide" would, if taken as mantra, excuse every sort of monopolistic or anti-competitive abuse that we've ever seen, which indicates to me that it's not a remotely valid argument.

In this case, Apple has, with a stroke of the pen, killed off several toolsets that compete with the one that they're trying to promote. It reads like a textbook example of tying, using control over a mobile phone application marketplace to kill off competition in the developer tools market, and it's almost entirely targeted at a single competitor (though there's plenty of collateral damage, as well, Unity et al).

I think Apple may have something to worry about here.

From what I understand, the problem was Microsoft tried to use its dominant position with Windows to achieve a dominant position in the web browser space in a manner that was considered 'unfair'.

What Apple is doing isn't trying to use its dominant position in the market for mobile applications to achieve a dominant position in the market for development tools, nor even in the market for development tools used to write iPhone applications.

Conceivably, you could use TextMate to write your code.

Conceivably, Adobe could write a better IDE than Xcode for Objective-C and Cocoa Touch programming

> Microsoft force you to use .Net (of some form) and their APIs because that fits their business model

You can always develop in Java with your favorite tools and transform the generated bytecode to .NET using IKVM. You can have your own abstraction on top of XNA and SDL, so you don't have to change anything when porting a game from the JVM to the XBox.

Nothing stops you from developing cross-platform apps, and in fact major games publishers are doing just that ... any game that's running on both the XBox and on Playstation 3 is using a intermediate layer.

Yeah, it's costly to distribute object code compiled from C/C++ or your tools of choice, but you have that option.

So wtf specifics are you talking about?

> If Microsoft had a clause saying that you had to use Visual Studio Ultimate on Windows 7, they would get demolished.

But XCode is free with every copy of OSX. If the same were true for Visual Studio Ultimate, I don't think it would be an issue.

OS X isn't.

Neither is Windows.

Couldn't you concievably develop with Mono, though?

Conceivably, yes, but that's beside the point.

My point is that comparing a Visual Studio Ultimate requirement to an XCode requirement is misrepresenting the weight of the XCode requirement. XCode is free and included with every copy of OSX, while Visual Studio Ultimate will set you back $3,800 (the cost of a well equipped Mac Pro). Requiring VS Ultimate would no doubt cause angry mobs to storm One Microsoft Way, but it is not a fair comparison by any means.

A more realistic comparison is that if Zune/XBox development required Visual Studio Express[1], which is a free download. And really, I can't imagine there being much backlash out of that. I wouldn't be surprised if it was currently the case.

[1] That's still a bit off since there is no up-sell from XCode, but for the sake of argument, say they are equivalent.

OS X is less expensive than Visual Studio, in fact you could probably get the operating system and a mac mini to go along with it for less than Visual Studio Ultimate...

That's the ultimate version.. Microsoft not only has much cheaper versions, but they also have free express compilers these days too (and have for years). But sure, pretend its 2008 still (at least the best video card available for the Mac Pro was slightly competitive at that time). Regardless, Mac's are heavily overpriced too. You have to own a mac to develop for the iPhone's. And you must use Apple software to develop for the iPhone.

And then you need Apple to censor your app (since they obviously know better than anyone what people should be allowed to buy).

And even after all that, Apple are using all of these, to kill Adobe (because that's what it's all about, since adobe is a competitor to Apple). Remember, when Aperture was first released, people were much more impressed with Lightroom, and Adobe hasn't lost much traction.

Anyway, Apple are treating developers like crap. Even if this is only a rumor, it is only a matter of time until antitrust trials get underway (for any number of things). In fact, I'm surprised they didn't happen sooner for the iPod's (which surprise surprise, use protocols to limit them to Apple's own software, which doesn't allow foreign music stores to be integrated).

And you have to buy Apple hardware to run it.

[Ignoring the context of this discussion] The fact that something is free doesn't automatically make it non-issue.

It just seems like a contrived comparison. If the same situation involving Microsoft is so obviously outlandish, why embellish?

As far as I can tell, there's no way to deploy an XNA game to the 360 that hasn't been built with Microsoft's toolchain. I think it's a bit early to speculate about the differences between the two platforms (iPhone OS and X360).

Reply on news.ycombinator.com