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.
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?
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.
> 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.
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.
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.
>> 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.
>> 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.
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).
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)
> 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.
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.
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.
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.
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.
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 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.
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).
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.
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.
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 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.
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.
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.
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.
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)
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.
> 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.
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.
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?
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.
"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.
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.
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).
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.
How do you know something is substandard just because it's made with some other library / language ? Especially with an "yet to be created" library / language ?
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 ?
It's a question of whether you want regulatory intervention preventing the possibility of there being "closed" systems in addition to there being "open" systems. If you prevent Apple from going their "closed" route, you lose the possibility of any benefits that might come from such a different model. When people say "let the market sort it out", they mean that if Apple's model puts out a significantly worse product than the more open models, they'll be forced to open up or die. So it's a question of whether all platforms have to be open: this would arguably lead to increased competition within each platform, but with less distinction between platforms and would prevent the possibility of exploring different models for whole platforms (and letting those models compete).
As long as Apple has the DMCA preventing a well functioning, commercial jailbreaking kit from being released with every model, I'm all in favor of them being pried wide open by the US government.
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.
I think there's certainly a certain bar of quality apple has in terms of the human interface guidelines / look+feel of the app. The fart apps might be crap, but they still look like iPhone apps. I have no desire and i can understand apple's desire to not want apps that have that shitty flash/flex look on the iphone. Now... if the apps look the same, I don't think this matters.
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?
They can enforce this by rejecting ugly apps (I hope they don't). These definitely don't look like iPhone apps, even though they are native: http://nativegui.posterous.com/
Interface guidelines and look and feel matter a lot less when you are making a game doing OpenGL. This is a big market where Flash apps could have competed quite nicely with the Objective-C apps and Apple is blocking that for no actual reason.
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.
What if market can't figure this out? It's an exaggeration, but what if discrimination by programming language ("Applications must be originally written in ...") is the version of [insert your favorite type of discrimination] applied to programming? You can't program in X for iPhone, so go write your programs for Android == you can't work in our company, but you can go work on plantation.
Maybe it's not the antitrust issue, but it's definitely a law issue: i.e. what can be enforceable by contracts.
Regarding d, you CAN (theorically) build an XNA game with any tools you want. It just has to be compiled to .NET bytecode and use the microsoft APIs for accessing system resources.
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#.
Since Apple doesn't have anything resembling a monopoly in any market it operates in, and since all DoJ can do is file a suit that is predicated on them having one, this is unlikely to go anywhere.
I don't think tying claims need to prove an actual monopoly, just the somewhat lower standard that the seller has sufficient market power in the tying product's market for the tying arrangement to restrain trade in the tied product's market. It's been applied in the past to car manufacturers who tried to corner their own cars' replacement-parts market, even though the manufacturers didn't actually have a monopoly in the car market.
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.
3.3.1 is a section of the Terms of Use of developers seeking to use Apple's distribution channel. Apple isn't trying to make middle-ware-built iPhone apps illegal. It just doesn't want them on the app store. An important distinction between the car/part and printer/ink analogies.
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).
>> 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
Cydia or the other jailbreak market (can't recall the name).
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.
hey we should institute this policy to stop people from porting our apps to Android
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.
Look at the antitrust lawsuits against printer manufacturers for ink refills. You don't have to have a monopoly in a sector (printers) to be subject to anti-trust laws, having a monopoly on consumables designed to work with your product can be sufficient.
Seems to me like the harmful to consumers aspect of the antitrust case will be the hard part to prove here. It seems like people are in near-universal agreement that printer companies were/are price-gouging on their inks in a way that is exclusively harmful to consumers. However, Apple's whole narrative on this TOS section is that doing otherwise would in the long run harm consumers by slowing down the evolution of the platform. Hard to see how the DOJ is going to prove otherwise.
Great, great point. The impact on the consumer is the bottom line for these laws. It's not the level of competition, how free the market should be, or how easy things are for developers.
The legal action that I'm aware of about printer ink alleges that HP colluded with Staples, paying them a huge amount of money, to prevent them from carrying a competing product.
But, as a counterexample, I'm not aware of a successful suit that challenged HP's use of printer cartridge rights management technology.
I don't understand how they are being anti-competitive. They control the entire stack from hardware to software. The fact that you can write any software for their platforms is more of a privilege than a right.
To further your comment danh, Apple has an absolute monopoly on App Stores on iPhone devices.
I can't get an app onto the device without going through them.
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.
Apple has an absolute monopoly on App Stores on iPhone devices.
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).
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.
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.
Your comment is an example of a false dichotomy. We do not have precisely two options:
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)
"[O]nly Apple's programming tools." This is completely wrong. Apple isn't restricting anyone from using, e.g., Textmate, they are requiring use of c/c++ and objective-c. These languages run on many other platforms, obviously.
The antitrust issue should really be about how apple is selectively enforcing this issue. I think the market can flush out the root issue in 3.3.1, but apple picking and choosing which companies can break the rule is really where the DOJ should come into play.
I wonder if we'll also see an inquiry into 3.3.9, which is about data collection and impacts mobile ad networks. If Apple's own mobile ad network can leverage data for targeting that other ad networks can't, I really can't see those ad networks just acquiescing without exploring their legal options.
Prediction: this will be a complete farce and probably even impede market correction of the problem.
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?
As much as I would like to protect the world from Apple with law... I don't think Section 3.3.1/Anti-trust are the way to go.
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.
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.