Antitrust inquiry into Apple over Section 3.3.1
nypost.com
nypost.com
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.
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.
Don't get me wrong. I'm right with you there.
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...
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).
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.
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.
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)
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.
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
> 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.
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.
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.
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 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.
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.
Regardless, one does not need a monopoly to engage in anti-competitive actions and for them to be illegal.
>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.
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.
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.
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?
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.
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.
As Jobs has explained, they've been burned before.
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.
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.
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.
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 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?
Should Apple outlaw 3rd-party Objective C libraries as well?
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?
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.
This has nothing to do with being a monopoly. When big companies do shitty things to undermine normal competitive forces they get scrutiny.
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.
Have you considered the possibility that it is not so clear and obvious as you think?
Couldn't you just use managed C++?
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.
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
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?
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.
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.
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).
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.
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?
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.
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.
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.
Kodak wouldn't sell parts to other parties.
Apple won't sell your stuff in their store.
There's a pretty clear difference here.
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.
However yes my statement was very much the same, however questionable comparisons to the console market may be.
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.
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.
a) The market will figure this out. If developers don't want to code in just Cocoa touch or make apps for other platforms a priority because the language is easier, they will.
b) Things are in such a nascent stage. Android is growing like a weed. A suit like this might make some partial sense a few years down the road if there was enough data there.
c) The department of justice will probably hire a bunch of people with no real domain expertise to look into the subject.
d) The potential precedent set could be scary. @archgrove mentioned the xbox example. So now, microsoft might HAVE to allow us to build XBLA games using any tools out there. If I were microsoft, I wouldn't want sub standard crap getting in there.
If you think "the market will figure this out" (which I think in itself is wrong) why don't we let the market figure out which language is better ? If the users don't like some products, they won't buy them. If all Cocoa touch apps make money and all the Flash apps lose money the market will fix itself, no ?
Once jailbroken phones are both legally allowed, easy to make, and required to be given all the same benefits non-jailbroken phones, they can make all the rules for their store they wish to.
Ex-post facto control of already purchased items is bupkis, bunk and any other old-fashioned word connoting completely illegitimate.
Is it a valid theory to say: this is less about the back end/performance issues and more about the front end/look+feel of apps?
Games consume a lot of resources (battery included) anyhow so it's really hard to claim doing it in Objective-C is in any way better.
Maybe it's not the antitrust issue, but it's definitely a law issue: i.e. what can be enforceable by contracts.
Nobody is saying that apple has to give developers the ability to run native code, or to use private iPhone APIs. What they are saying is that Apple shouldn't be able to require us to use C/C++/Objective C to create the executable. That would be like Microsoft requiring XNA to be build with C#.
If i have an xbox, I can get a game from Best Buy or Amazon, etc. Even though those are closed systems.
If I have an iPhone, I can only get apps from the Apple store.
I'm not positive if this is unique to Apple in the mobile space or not. I know I can get blackberry apps from anywhere, same with WinMo. I'm not sure about Android or Palm.
That may not qualify as a "relevant market" for determining monopoly status. (The Conclusions of Law from the MS v DOJ case makes interesting reading along these lines).
http://www.justice.gov/atr/cases/f218600/218633.htm
Whether this zone of commercial activity actually qualifies as a market...depends on whether it includes all products "reasonably interchangeable by consumers for the same purposes." ..."Because the ability of consumers to turn to other suppliers restrains a firm from raising prices above the competitive level, the definition of the 'relevant market' rests on a determination of available substitutes."
So if a plaintiff were to try to argue that Apple is the sole supplier of App Stores for iPhones, it would become germane that nothing is charged for access to this service, and that if access became expensive consumers could flee to other smart phones.
It's hard to prove, though, because it tends to require showing that the company did the tying solely or mainly for the purpose of restraining trade, as opposed to for some legitimate purpose. The car manufacturers lost because the courts didn't buy their argument that their attempts to limit the replacement-parts market were for quality-assurance reasons. Apple would have to argue that section 3.3.1 isn't intended mainly or solely to stop cross-platform compatibility, but has some legitimate, non-trade-restraining purpose, like improving the reliability or quality of iPhone apps. Probably even just "it makes it easier for us to review apps if they're all in the same languages" would be a good enough explanation. A bad result would be a leaked smoking-gun email saying "hey we should institute this policy to stop people from porting our apps to Android".
Monopoly leveraging is a separate (but related) concept, as far as I understand it, and a bit easier to prove, because there's a much stronger presumption that if it's happening, it's bad, regardless of the reasons.
(Edit: edited/expanded a bit for clarity)
Remember when he replied to that blogger saying he agreed with Gruber followed by something sort of like the above? Would be mighty ironic if one if his tiny glib emails ended up taking down the company.
Forcing Apple to repeal 3.3.1 doesn't allow offending software to be built and sold (as it already can be), it forces Apple to stock its shelves with it and thus take on users' expectations that Apple will support it (by making sure an OS update doesn't break hundreds of apps by running afoul of a popular middleware package).
Where else exactly could they go?
>> Forcing Apple to repeal 3.3.1 doesn't allow offending software to be built and sold (as it already can be), it forces Apple to stock its shelves with it
Those two things are the same, by Apple's design.
Those certainly aren't remotely equivalent options, but my point was just that 3.3.1 is about Terms of Use for the App Store, not an attempt to legally stifle an existing secondary market as with car parts and ink cartridges.
It's thus a qualitatively different situation.
More relevant precedent might be found by looking at other situations where service providers have added terms to limit allowed devices/tools.
But, as a counterexample, I'm not aware of a successful suit that challenged HP's use of printer cartridge rights management technology.
If Steve Jobs is right, and the progress of the platform is really slowed by cross platform toolkits, then intervention would literally slow down the progress of computing, and possibly set a precedent that slows progress indefinitely. If by being right, Apple ends up in a more dominant position, that won't prevent Google and Microsoft from altering their own strategies to compete. Both of them still have massive market power they can leverage.
If he's wrong, then surely he's handing a serious competitive advantage to Google, Microsoft, RIM, Nokia etc, and as all the cool apps start to appear on all of these platforms along with a plethora of interesting and cool devices, Apple will shrink back to a minority player differentiated only by style.
I think it would be a terrible for both sides of this debate if the outcome is determined by judges and Apple is not allowed to take this risk.
A) He's right and forcing them to allow frameworks will slow computing as a whole B) He's wrong and cool apps will start to appear on all the competing platforms
There's also, just as one example:
C) He's wrong but large numbers of cool apps will not start to appear only on competing platforms (perhaps because the app markets on all those platforms combined are dwarfed by Apple's App Store)
Also; I thought 3.3.1 wasn't in force yet? We still have no practical examples of where Apple will enforce this. Surely that is important before talking about action?
This can totally destroy small companies that have invested heavily, and are still waiting to be approved.
In a sense it reminds of the XBLA slots (commercial Arcade).
I just don't see the connection... Apple aren't encouraging programmers to choose between Apple or other platforms - just the ones inept enough to need the crutch of Flash (or similar) to call themselves programmers to start with. Writing cross platform code is precisely as possible as it was before 3.3.1 - its just not so easy that every idiot can do it and submit their rubbish to the App store.