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.
Should Apple outlaw 3rd-party Objective C libraries as well?
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.
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?
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.
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?
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?
Couldn't you just use managed C++?
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.
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?
This has nothing to do with being a monopoly. When big companies do shitty things to undermine normal competitive forces they get scrutiny.
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).
>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.