New iPhone Agreement Bans Flash-to-iPhone Compiler & Others - <AUTHOR> http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler <comment><USER4> Getting away from the frenzied rhetoric, my opinion is that what Apple _really_ wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that.

In my experience so far with such "cross platform compatibility layers," they always produce results that water down each platform's individual strengths and differentiations. And of course, instead of the developer being locked into the phone platform, they are locked into the compatibility layer's platform.

Adobe's Flash compiler is a classic maneuver to "commoditize your complements," as Joel put it so well. Apple don't want to be commoditized, especially if it means having apps that don't take advantage of the iPhone's strengths.

Adobe want to lock developers into Flash and commoditize everything else as Flash-delivery devices. Apple want to commoditize applications and lock developers into their APIs.

<http://www.joelonsoftware.com/articles/StrategyLetterV.html>

<comment><USER5> If the cross-platform experience is subpar, Apple should just let these apps fail in the market.

<comment><USER6> "If the cross-platform experience is subpar, Apple should just let these apps fail in the market"

Perhaps, like Nintendo, they learned the lessons from the collapse of the home video game market in 1983. When Nintendo was contemplating developing the NES, they took a deep look at what had caused the collapse. What they concluded was that the main cause of death was the market being flooded with too many crappy games.

Originally, if you wanted to write, say, an Intellivision game, you went and got a job with either Mattel or APh Technological Consulting (the company that did the hardware design, system software, and many of the early games for Mattel). If you wanted to do an Atari game, you went and got a job with Atari.

The games at this time were all pretty good. A consumer could go out, buy a game based just on the information printed on the box, and go home and be pretty sure they'd have a good experience.

As time went on, a few more companies joined the party. Activision and Imagic, for instance. These companies were started by people who had worked for Mattel or Atari or their contractors like APh, and generally produced quality games.

A consumer still could be confident that plunking down $40 or whatever for a new game, based just on the box description, would be a good move.

More time passed, and companies that had little or no connection to Atari and Mattel jumped in, using information gleaned by reverse engineering the consoles and system software. The information was not always complete, and they didn't know all the tricks and techniques we authorized developers knew to squeeze greatness out of the hardware. They produced a lot of crap games.

Consumers now found that spending $40 on a game was a big gamble. They had to work to get good games--be aware of brands, read reviews. They stopped buying --all games, not just the bad games.

Nintendo's conclusion was that their new console must be locked down. Only developers that Nintendo approved would be allowed to produce cartridges. This way, they could ensure that quality remained high, and get the now shy consumers to come back and give games another change.

It clearly worked--and consoles have been locked down ever since, and the console game market is huge.

<comment><USER7> This is exactly what I thought the original app approval process would be for: an Apple "seal of quality". That would be a fine trade off for users -- they may only get the approved apps, but at least they're screened for quality.

However, that isn't what the approval process is. There are literally thousands of crappy applications that were happily approved and clogging up all categories in the app store. It seems non-trivial app rejections are not done on behalf of the user but are done solely to protect Apple's own interests. Remember when a bunch of high-quality Google voice apps disappeared from store? And that's just one example, there have been many more.

And now they're rejecting apps not based on their quality, but based on the programming language or development environment used to create them. How is that at all relevant to the user? This is entirely about protecting Apple's own interests and the comparison to Nintendo's lock down of the NES is not applicable.

<comment><USER8> > This is entirely about protecting Apple's own interests and the comparison > to Nintendo's lock down of the NES is not applicable.

What I don't understand is how this isn't anticompetitive behaviour. By creating an app store and lock-in for application vendors, Apple become the only provider in the market. They now appear to be leveraging that monopoly to restrict another market, that of developer tools, to their commercial advantage and at the expense of a competitor.

I'm not a lawyer and don't live in the US where presumably any legal action would be brought, but can someone please explain to me how this isn't black- and-white illegal under US law?

<comment><USER9> Apple's market is one of their own making, and is in fact something of a submarket. They control the platform, period, and when you agree to the terms of their developer agreement, you agree to be bound by them, so you are subject to the same rules as everybody else. They don't have any market monopolized, they merely have their corner of the market locked down.

and they aren't locking in any body. You don't forfeit rights to your source code, you're welcome to write some crossplatform app using some shared code library you build in-house. You just have to build apps natively, rather than use some watered down piss poor Common language that breaks standards on all platforms. This is the same reason adobe apps suck on macs. They have tried to abstract away the os from their applications to the point where they don't look, act, or function properly on any platform. They look like ass and run like ass on everything .

<comment><USER10> Adobe apps function great on windows and better than Macs on linux... have you ever considered the fact that your overpriced mac is what sucks? no - <USER2> Jobs told you it was Adobe's fault.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I don't like this at all. Maybe they only meant to hit Flash, and maybe not, but as written this is in direct opposition to one of the most important principles of software development. Apple themselves must have benefited countless times from writing software in layers. But no layer above their layers is permitted?

I wonder if the open source world can successfully fight back, by making compilers that generate code the app store police can't tell from hand written.

<comment><USER12> _I wonder if the open source world can successfully fight back, by making compilers that generate code the app store police can't tell from hand written._

I think the answer is definitely yes. Apple's software engineering is not that great. There is always some hole in Safari that allows root access to the entire device. They can't get atomic syscalls working in OS X. Does anyone really think they can recruit and afford people that can tell computer- generated software from hand-written software?

My guess is that this is a scare tactic to keep anyone thinking of supporting two platforms at once to "not want to risk it" and go for the iPhone instead. More users, only so many hours that the developer can be awake, safer to just go with the iPhone. (Of course, you are already risking it anyway; use the wrong multi-touch gesture -- app denied. Use a Google service -- denied. Do something useful that Apple wishes they thought of first -- denied. And people wonder why there are so many fart apps...)

My next guess is that this tactic will be successful. People seem to adore doing whatever Apple tells them to do. It frightens me.

What I've learned from iPhone vs. Android (among other things) is that people will pick pretty and mean over average and nice.

<comment><USER13> I am not sure that it'll be exceedingly difficult to determine if an app was compiled using another tool, and not written in Objective-C.

I'd expect many languages and frameworks are going to have many very signature functions and patterns of code. If Apple decides to enforce this, they won't have a hard time.

On top of that, if they miss it, and let a bunch of apps in, then later on determine those apps were crosscompiled, they can revoke the current versions and block that developer...

<comment><USER12> But of course, this makes for unhappy users too. "I just lost the $5.99 I paid for that app!"

<comment><USER14> NetShare users kept using the app months after Apple pulled it. I think people finally stopped using it to tether because an update finally broke it, not because Apple deleted it off people's phones…

</comment></comment></comment></comment></comment><comment><USER15> I don't really have a politically correct way to say this: What a horseshit maneuver by Apple.

<comment><USER16> I have been a very loyal mac user for years and love it, but I'm seriously considering going back to Linux. I am not a free software "zealot" and don't mind some closed-ness, but this is getting absolutely insane.

Enforcing which _LANGUAGES_ can be used on a platform?!? Insane!

Edit: I've been looking at these guys:

<http://www.system76.com/>

(I don't work with or have any vested interest in them, but they look cool.)

<comment><USER17> Boycotting the Mac platform (which is pretty much free of any such absurdity) doesn't make a lot of sense to me. That's where Apple is doing things _right_. You should of course, shun iPhone OS devices if you feel this way.

The system76 laptops are probably generic machines from Clevo, Sager or some such with a custom badge. Alienware used to do the same thing.

<comment><USER16> The hardest thing to me about ditching Mac would be that Apple is the only company capable of doing a user interface.

ALL other user interfaces by ALL other vendors suck.

For some reason, no human beings on the entire planet other than those that work at One Infinite Loop in Cupertino are capable of doing a UI.

<comment><USER18> This is a massive exaggeration. I went from OSX to Ubuntu and I am more productive on Ubuntu in interface terms. The dock is very silly and graphical when you have quicksilver or gnome-do. Chrome is a better browser and browser UI experience than Safari in my opinion (and lots of people like firefox and opera more). The Finder vs Nautilus differences aren't big enough really, there are pros and cons to each. Apple stuff is well designed until you want to go past just cookie cutter customizations and then the openness IS the UI because I define it to work how I want to.

The same caries over to other things. Sure the install and uninstall of applications on OSX is a great UI. But apt-get just seriously leaves it in the dust. The problem with linux was never that it had a bad UI or was too customizable. The problem with linux was actual hardware bugs in drivers, lack of office, lack of flash, lack of games. Which have mostly been addressed asides from games (which is a sore point for Apple too). UI is far too overrated over actual features.

And it's all based on a myth. Steve Jobs ringing up SUN over their looking glass and threatening with UI patents is just ridiculous. As are the claims to Apple fame with interfaces taken from Xerox.

So yes, I agree Apple are very good, possibly the best at UIs. But my points are 1) UIs aren't as massively important as people say, 2) Apple's "innovations" have been overrated 3) your statement that "no human beings on the entire planet other than those that work at One Infinite Loop in Cupertino are capable of doing a UI" is just ridiculous.

<comment><USER19> As much as I agree with the "it's not that bad" opinion, I can't understand why do you say "UI is far too overrated over actual features". No "standard user" will want to know about apt-get. They have synaptic and others. Normal users don't want to use the console at all. Command line is good for developers and power-users - and that's a minority. Majority wants to work based on recognition, not recall because they don't care enough to remember things.

<comment><USER20> I agree, that's why Ubuntu comes with the "Ubuntu Software Center" which is basically a frontend for those tools my grandma could use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Putting aside the intention of this agreement which does seem targeted at the Flash-to-iPhone compiler, this just seems overly broad and silly from a "how things work" point of view.

Let's say I write an iPhone app originally in Scheme (like this guy did: [http://jlongster.com/blog/2009/06/17/write-apps-iphone- schem...](http://jlongster.com/blog/2009/06/17/write-apps-iphone-scheme/)), and compile it down to C, which is then compiled to object code and linked against the iPhone libraries. At this point, the object code is the same (or functionally the same in terms of its syscalls, library calls, and general program flow) as if I had originally written it in C, except that I would have lost the unique developer efficiencies I got from using Scheme in the first place. I'm not saying Scheme is better or should be an officially sanctioned source language for the iPhone SDK. I'm just saying, where the rubber meets the road -- object code linking against libraries and making certain calls -- there is no difference to the computer what the original source was.

Seems very silly.

<comment><USER22> I had the same thought and wondered, if a developer did follow such a path, how would Apple identify that they did? I'm not sure Apple could detect that such a method was used. Although, I suppose they could ban an app even if they only suspected that it had been developed in such a fashion.

<comment><USER23> 1) They may not be able to detect all frameworks, but they will easily be able to detect the top N frameworks, where N scales with how serious they are about enforcing this.

2) The app approval process is so opaque that it might be hard to tell if they were banning you due to this reason (note I hear things have improved, so this point may be out of date).

</comment></comment></comment><comment><USER24> Say hello to the new boss, same as the old boss. The corporate pissing matches have started in earnest...

When Alan Kay said Apple would take over the world with an iPad, I don't think he realized that eToys or anything like eToys would never be allowed to run on the device and that a majority of the apps will probably have commercial spots embedded within them. Actually it reminds me of "educational" tv all over again...

I'm starting to see the point of people who complain about the consume vs. create nature of the iPad...

<comment><USER25> "a majority of the apps will probably have commercial spots embedded within them"

The majority of apps on the app store already _do_. Free apps, ad-supported. Apple just wants the ads to not suck so much, but hey, nobody has to use iAds.

<comment><USER26> _but hey, nobody has to use iAds_

Yet.

<comment><USER25> Well, Steve did flat-out say in the Q&A session today that they weren't going to require anyone to use their built-in services for any of that, and Apple doesn't really have a history of changing what they've said they're gonna do.

<comment><USER26> I don't know one way or the other about their history of going back on direct claims, and that would be a pretty sprawling area to get real data on. But they certainly do have a history of locking the phone OS down more and more and controlling it further and further.

I really wouldn't put it past them, and I think today's a bad to err on the side of "things won't change."

</comment></comment></comment></comment></comment><comment><USER27> Wow, this could also ban iPhone apps from using Scheme ([http://jlongster.com/blog/2009/06/17/write-apps-iphone- schem...](http://jlongster.com/blog/2009/06/17/write-apps-iphone-scheme/)) or maybe even model-driven tools (<http://code.google.com/p/iphonical/>).

Telling developers which languages to use? Might as well stick with enterprise software development, more innovation going on over there Apple!

<comment><USER28> Actually, yes. My employer caters to the enterprise market, but we use, say, Ocaml and Python, and are experimenting with Haskell.

</comment></comment><comment><USER29> I can think of only two (tenuously) justifiable reasons for this.

1 - Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than "My App doesn't WORK!!!!! (Using MonoTouch Vxxyy)", they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified.

2 - If it's specifically to target cross-compilers as a business decision, to ensure that iPhone only gets "exclusives", then I suppose it's their prerogative. It will probably backfire long-term, as their market share isn't _that_ dominant. "Browser, Palm, Android + all else" or "iPhone" makes the iPhone a secondary port target versus a first class platform.

If it's any other reason, it is ridiculous. It makes me seriously question my upcoming Mac Pro & iPad purchases. Even though I currently develop for Mac and iPhone using only Obj-C, I can't build a development strategy around a schizophrenic "partner". What's next - documentation not written in Pages? Failure to use Steve's favourite colour in the background? It's getting... bizarre.

<comment><USER30> Surely there's also the approval process?

Checking an app isn't doing anything malicious may be easier if it's written with standard tools.

<comment><USER31> I don't see how. They don't ask for source when you submit your app, so it shouldn't matter at all what language you "originally" wrote the app in. This is just a bullshit control-freak move. Apple has stopped looking out for the interest of it's users and has started looking to punish it's competitors. Epic fail. <sigh>

<comment><USER32> You mean Apple has stopped looking out for the interest of it's developers... If anything, Apple listens to their users better than any of their competitors. Try convincing an average 17 year old girl to buy an android/zune over an ipod touch for her music.

I think the situation will only improve when Google actually cares about their users and less about the cool tech that comes with every phone.

</comment></comment></comment></comment><comment><USER33> This is unsavory in the extreme. I had been writing an iPhone app in Haskell, and now I have to can it? What the fuck? Fuck you, Apple! Blowhards.

Hope you guys enjoy the mass exodus of decent developers from your dumbass platform with kiddie languages.

<comment><USER12> GHC has a C backend. Just claim that you wrote that code yourself. Problem solved.

<comment><USER33> I don't want to invest months of my life, only to be told, "sorry, if you can't prove it's C, your app is rejected. Bye."

<comment><USER12> Yeah, then stop supporting their hardware. If you just bend over in front of them, of course they're going to fuck you.

</comment></comment></comment></comment><comment><USER12> Who's going to know? My C happens to look _exactly_ like what Chicken Scheme generates!

<comment><USER34> If everybody's C starts to look like what Chicken Scheme generates then you've (Apple) just detected Chicken Scheme.

<comment><USER12> Or I'm just ultra-productive and very helpful to The World At Large.

</comment></comment></comment><comment><USER35> Isn't MacRuby sponsored by Apple? There's been discussion re: writing iPhone apps with MacRuby, AOT compilation. I wonder how that project will be affected?

[http://lists.macosforge.org/pipermail/macruby- devel/2010-Jan...](http://lists.macosforge.org/pipermail/macruby- devel/2010-January/004049.html)

<comment><USER36> It's not MacRuby, it's RubyCocoa, but yes, they have their own project using a language not included in this list. No, I'm not expecting consistency here against their own "baby", but what kind of environment does this set up? Would you even want to use RubyCocoa in this environment, much less a 3rd party language bridge to Cocoa (which is 100% targetting Apple's platform and APIs).

<comment><USER37> MacRuby and RubyCocoa are two separate projects. MacRuby is not a Cocoa bridge like RubyCocoa is. It's a complete reimplementation of Ruby's primitives in Objective C to allow you to compile a Ruby app to a double-clickable app bundle.

</comment></comment></comment><comment> jim-greer 'Additionally, developers may not consume energy drinks or snack foods with preservatives while developing Applications'

</comment><comment><USER38> > Applications must be originally written in Objective-C, C, C++, or > JavaScript as executed by the iPhone OS WebKit engine

Controlling programmers like this seems positively insane, doesn't it? Does this mean that games can't do scripting in something like Lua either, under the letter of Apple's law?

<comment><USER39> Games never could do scripting in Lua, since you can't run interpreted or Jitted code on the iPhone anyway.

What they are forbidding now is the usage of any third-party compilers that are producing native executables ... Adobe CS5, MonoTouch, Unity.

<comment><USER40> > _any third-party compilers that are producing native executables_

It's more than that. They are forbidding you from writing it in 'language X,' converting 'language X' into C/C++/ObjC, and then running that through Apple's developer tools. They state that the program must be _originally_ written in C/C++/ObjC.

</comment></comment></comment><comment><USER41> Oh man, just when I was impressed with what they're doing in iPhone OS 4.0, they throw this in.

I was hoping to finally develop for the platform thanks to background services, but my moral objection is now at par with my profit motive.

<comment><USER32> um, what does morality have to do with this? Apple's rules are not immoral. It's their platform and they're not a monopoly. If you don't like it, choose a different one.

</comment></comment><comment><USER42> Hey lookie there, I can return this iPad still. I'll go buy a second android phone for my Development shop. Great Job Apple!

<comment><USER43> Sounds like a grea business decision

<comment><USER42> Honestly, I'm not returning it, but I hope other people do realize they have some relatively serious power over apple for the next 20 or so days.

</comment></comment></comment><comment><USER44> Wow. Just wow.

I was planning on building an app in Titanium. I guess I'll wait and see how this shakes out first.

btw, at the time of writing this comment Titanium's developer center is hosed. Maybe it became self aware at the same time and commited suicide.

<http://developer.appcelerator.com/>

<comment><USER45> Same here. I've even built prototypes that I was planning to turn into full- fledged apps. Titanium had the best chance of me building apps for the iPhone. If Apple doesn't allow it, well, tough beans. Sorry users, Apple screwed you. My apps, however, will be available on all Android platforms.

</comment></comment><comment><USER46> 1\. Apple takes iPhone stability and security Very Seriously.

2\. ???

3\. Therefore, if you write native iPhone apps, you must use C derivatives that expose raw pointers and direct memory access.

<comment><USER47> Yeah, as if Flash is known for its stability (especially on the Apple platform) and security…

<comment><USER33> This affects anything that isn't C, C++, or Objective-C. Pay attention.

<comment><USER47> Yes it does. My comment was about Flash however.

<comment><USER32> you're preaching to the choir already. I'm pretty sure we're all in agreement on how sucky the Flash runtime is already.

</comment></comment></comment></comment></comment><comment><USER48> Welcoming explanations for how this is a good thing for Apple's end users.

<comment><USER49> Because the apps will be running on controlled development libraries that might be able to.... perhaps multitask in OS 4.0, remember guys this is a phone we are talking about here, not a games console, security is paramount, and apple is just trying to put the the genie back into the bottle before a mass of insecure apps are elevated up the permission chain in 4.0 to be able to operate on a par with apple authored apps.

<comment><USER36> using a different language doesn't affect security, the executable is still within the same sandbox. please read up on the plethora of projects allowing other languages to work with Cocoa, including desktop OSX, including Apple- funded projects like RubyCocoa.

</comment></comment></comment><comment><AUTHOR> Is there a legitimate reason for this, or is Apple just thumbing their noses at Adobe (and everyone else)?

Is Apple primarily annoyed that Adobe's app and MonoTouch aren't doing it the "Apple" way? Or do they not like that those frameworks present non-standard UI's (I haven't used MonoTouch, so I don't even know if that's the case here)?

<comment><USER50> Apple might say the rationale is to allow easier inspection of apps for policy compliance. (Even though other languages compiled-to-approved-languages will be the same for _automated_ analysis, it's more likely the code will be inscrutable to human reviewers.)

<comment><USER51> You don't submit your source code to Apple. Why should this matter?

<comment><USER52> You raise an interesting question. Perhaps they'll require source-code to be submitted in the future?

<comment><USER53> It would greatly surprise me if they did so, not least because every new piece of Apple software might get hit with speculative IP lawsuits if they had any features that bore even the most remote similarity to an iPhone app for which the developer had submitted code...even a company as wealthy as Apple would weep at the compliance costs.

But the indirect effect would be to shut people up. Rather than spending much or any effort on peeking inside iPhone apps looking for signature traces of cross-compilation, Apple would benefit because people would stop talking in public about which 3rd-party development platforms they had used for their cool new app, out of fear that mentioning anything besides C, C++ or Obj. C might result in their app being taken off sale - so without Apple doing a single thing different at the technical level, this license provision would have a chilling effect on discussion about competitors' development tools.

</comment></comment></comment></comment></comment><comment><USER54> Looking forward to Adobe's response. Going to wager it'll be in the form of a lawsuit, and that the FCC will get involved. Whip out the marshmallows, this should be interesting :)

<comment><USER55> As much as I dislike this particular move, and Apple's Orwellian control over their platform, bringing this to a lawsuit and getting the FCC involved would be straight-up _wrong_. Let the market decide this one, Adobe has no legitimate ground whatsoever to force Apple to support it.

I would be hugely disappointed to see Adobe pursue this course of action, and would regard it with significantly more contempt than I currently hold toward Apple.

<comment><USER56> the market is fucking clueless. it's entirely possible that the path from where we are now to completely locked down "appliances" has monotonically increasing user experience. that doesn't mean it isn't an abysmal local maxima though.

</comment></comment></comment><comment><USER57> While Adobe is going to bear the brunt of this, this looks like a calculated move against Android as well. By precluding things like PhoneGap (if it turns out that it's "an intermediary translation or compatibility layer"), they're forcing developers that can only afford to write an application once to choose one platform. Right now, iPhone is the easy choice for a lot of developers, just based on market.

The end result being fewer apps for Android and a less vibrant software ecosystem.

<comment><USER58> Yeah, but if someone writes a compiler that compiles apps natively written for the iphone into android apps, Google will allow that and Apple can do nothing to stop it. So in a way this will mostly hurt Apple.

<comment><USER7> But Apple will still be the first-class platform and Android will be the second-class citizen in that scenario.

</comment></comment></comment><comment><USER59> "Applications must be originally written in Objective-C, C, C++, or JavaScript"

So porting from another language is now forbidden? Or is it unoriginal code that is banned?

Either way, the sheer craziness is astounding.

</comment><comment><USER60> In principle, couldn't any of these translation layers be converted to code generators that would produce compiled Obj-C that would fall within the rules?

Surely they aren't saying that all code has to be entirely hand-written? If so, then is running search-and-replace on a source file not allowed?

<comment><USER61> the wording says "Applications must be ORIGINALLY written in Objective-C, C, C++, or JavaScript"

<comment><USER60> It seems absurd and unenforcable; I mean, applications are _originally_ written in my head.

<comment><USER62> Since Apple completely controls the App Store and reserves the right to refuse any app for any reason (and have shown time and again they are willing to exercise that right), how could this possibly be unenforceable? It is their way or the highway. What is or isn't enforceable is entirely up to them.

Note: I am in no way saying that Apple's stance on this situation is a good one or not, in face, absurd. The iPhone 3G is the last Apple product I will ever buy because of this and other iPod/iPad related anti-developer bullcrap.

<comment><USER60> Unless they start auditing source code and everyone's entire development process, there are lots of ways in which such a rule could be violated that would be completely undetectable (and some cases that would be easily detectable too).

<comment><USER53> Quite, but would you admit publicly to having done so?

</comment></comment></comment></comment></comment></comment><comment><USER63> Due to time mostly, my Port of Cocos2D to MonoTouch (<http://github.com/city41/cocosnet>) has gone untouched for sometime. Looks like that was inadvertently the correct decision :(

Damn Apple is evil.

</comment><comment><USER64> Before you know it they'll be adding clauses like "Code for your application may not be written on Sunday".

</comment><comment><USER65> I'd love to see something like Logo or MIT's Scratch for the iPad. As I think about introducing my kids to computers that totally makes sense. This new language from Apple seems to preclude that.

It is totally off base.

<comment><USER66> Interpreters were already prohibited.

<comment><USER36> Interpreters being banned is old news, this is about compiled stuff being rejected because you chose a 'wrong' language.

<comment><USER66> That's what I said. The comment I replied to is about the potential for educational apps that require interpreters, which were already prohibited.

</comment></comment></comment></comment><comment><USER5> The App Store has always been a set of moving goalposts, but Apple just moved them completely out of the end zone.

Such a relocation tends to be more visible from a distance.

</comment><comment><USER67> Wow, color me totally surprised. Apple treating their developers badly? Say it ain't so.

</comment><comment><USER68> There is no longer any debate as to who the "bad guy" is in this story -- Apple has proven themselves to be anti-competition, anti-developer, and anti- consumer.

Just created a new "I'm with Adobe" Facebook Group:

<http://www.facebook.com/group.php?gid=113492765344092>

</comment><comment><USER69> I find it same time amusing and hard to believe that this kind of requirement (writing apps only in C++ & Obj-C) is legally possible.

<comment><USER40> I'm pretty sure that it's legally possible. It's a contract and I don't think that this restriction would be struck down by any court as being not valid.

<comment><USER42> Contracts of adhesion often are often found Unconscientious and not enforceable.

</comment></comment></comment><comment><USER42> I'm surprised ADBE isn't going down: [http://finance.yahoo.com/echarts?s=ADBE#chart1:symbol=adbe;r...](http://finance.yahoo.com/echarts?s=ADBE#chart1:symbol=adbe;range=1d;indicator=volume;charttype=line;crosshair=on;ohlcvalues=0;logscale=on;source=undefined)

<comment><USER70> ADBE isn't going down because the market closed before the implications of this situation became obvious. For that matter, they're still not entirely obvious. But you can bet they're going to open down tomorrow.

</comment></comment><comment><USER71> This feels wrong on so many levels...

Basically, they reserve the right to ban any sort of DSL/runtime/engine application architecture. Imagine you are building adventure games (like Money Island). You'd have a game engine and a domain language in which you describe the game. The beauty of this is, you don't have to rewrite the engine every time you finish a story for a game, you just write in your DSL. The same holds for a range of other applications such as travel guides, recipes for cooking... How can you be sure where they draw the line between data and code?

Well, it probably just depends on whether it comes from an Adobe tool or not. Let's see who's next.

</comment><comment><USER72> Can someone put up a link to the full text of license?

<comment><USER36> Click the title of the original post. New licence quoted in Gruber's story.

</comment></comment><comment><USER73> Apple's going to annoy a lot of big developers with this. Who's going to use Game Center, when a lot of big games are written with the help of Unity, etc.? There are so many top-10 games affected by this.

Even THQ's Star Wars: Trench Run is affected. You can't really get more high profile than that. I wrote a blog post (<http://bit.ly/disQ2C>) with some links to various SDKs and their app showcases to give people a bit of an idea of just how many existing apps this SDK change will effect.

</comment><comment><USER74> Compared to the video game console industry, this is still pretty nice. Several of the companies require submission of the _source code_ for review. And Nintendo in particular is renowned among my video game programming friends for having ridiculous, undocumented rules that change over time.

If you think of the iPhone as a PC-like platform, yes, it's worth being crazy. But I think of mine as more like a game console. That helps me minimize my own feather ruffling, even when Apple does snarky things to me during the review process.

<comment><USER75> Simply you are mistaken, and that's not true (submitting the source code).

First of all, lots of companies do license many 3rd party libraries, without their source code. Sometimes these said libraries are specifically compiled with latest bugfixes to the relevant project they've been used.

What the companies might require is usually symbols/debug information/etc. But never the source code!

After all, Microsoft, Sony, Nintendo are direct competitors. Why should an independent publisher (EA, Activision, THQ, Konami) be sharing source-code with them?

<comment><USER74> I am clearly misinformed and apologize for my mistake!

</comment></comment></comment><comment><USER76> This could mean instant death for MonoTouch. What developer would choose to write an iphone/ipad app in MonoTouch with the risk of having to re-write their app if apple drops the hammer.

<comment><USER7> What developer would choose to write an iPhone/iPad app with the risk of having to re-write or trash their app if apple drops the hammer.

<comment><USER77> _What developer would choose to write an iPhone/iPad app with the risk of having to re-write or trash their app if apple drops the hammer._

Your comment is emitting dangerous levels of irony.

</comment></comment></comment><comment><USER78> Is it not possible that all this fuss is over a typo?

> 3.3.1 — Applications may only use Documented APIs in the manner prescribed > by Apple and must not use or call any private APIs. Applications must be > originally written in Objective-C, C, C++, or JavaScript as executed by the > iPhone OS WebKit engine, and _only_ code written in C, C++, and Objective-C > may compile and directly link against the Documented APIs (e.g., > Applications that link to _Documented_ APIs through an intermediary > translation or compatibility layer or tool are prohibited).

My thought on what they probably meant:

> 3.3.1 — Applications may only use Documented APIs in the manner prescribed > by Apple and must not use or call any private APIs. Applications must be > originally written in Objective-C, C, C++, or JavaScript as executed by the > iPhone OS WebKit engine, and code written in C, C++, and Objective-C may > compile and directly link _only_ against the Documented APIs (e.g., > Applications that link to _Un_ Documented APIs through an intermediary > translation or compatibility layer or tool are prohibited).

I bet what they're trying to do is prevent intermediate tools from allowing people to "whitewash" private API access.

I say this because the interpretation everyone else is seeing in this clause is obviously a horrible position, and I just don't think that's the intent.

Time will tell!

</comment><comment><USER79> Apple has pursued a single consistent goal under the reign of King Jobs II: protect the ecosystem, and grow it in careful, measured increments.

In order to keep something great from turning to crap, you have to have a gatekeeper. If you don't trust the gatekeeper, that's OK. But I'm hearing a lot of noise from developers who are already beholden to their own gatekeepers (whether it's the core team of your open source project, Microsoft, Oracle/Sun, or whoever). I mean, Adobe?! Could there be a more arbitrary and horrible gatekeeper than Adobe?!

Just because Apple doesn't do what you want doesn't make them better or worse than any maintainer of any "good thing". In the end, it all boils down to whether you trust Apple to do the right thing.

If you don't, then you're welcome to go punt on the umpteen device platforms that are currently vapor. (How many years have we been hearing about "iPod killers", and where are we with that?)

It's OK to complain, but I really would have thought the HN audience would understand that EVERYTHING EVERYWHERE is a trade-off. Yes, we should be debating the rules that Apple imposes, because we have a say in that. No, that doesn't validate rhetoric about Apple being "evil" or "anti-developer" etc.

<comment><USER80> > developers who are already beholden to their own gatekeepers (whether it's > the core team of your open source project

I couldn't disagree more. The goal of free software is to ensure nobody has that kind of control over you and your tools. If you don't need to organize a fork, great, but they've already agreed they can't stop you.

As for the rhetoric, making tools is what makes you a member of our species. Agreeing not to is more like serfdom than partnership.

<comment><USER79> Then go ahead and fork Flash. LOL.

And forking is obviously less-than-ideal in terms of maintaining against future core updates. It's a kind of "freedom" that comes with plenty of new burdens.

</comment></comment></comment><comment><USER33> What's next? A requirement on what languages I'm allowed to think in? Not allowed to think thoughts that impinges Apple or one of its partners?

</comment><comment><USER81> Would Adobe have a valid antitrust case with this?

<comment><USER82> Nope. Apple doesn't have a monopoly in the phone market.

<comment><USER6> "Nope. Apple doesn't have a monopoly in the phone market"

It's a common misconception that you have to have a monopoly to run afoul of antitrust law. You don't. It also goes the other way--having a monopoly is not necessarily a violation of antitrust.

For instance, mergers have been shot down on antitrust grounds even when the merged companies would have had under 50% of the market.

Antitrust is more about the effects of actions on competition, rather than market share, although there tends to be a correlation between the two.

<comment><USER83> Thank you, good sir, for posting this reasoned, thoughtful, and accurate post.

<comment><USER83> People disagree?

</comment></comment></comment></comment></comment><comment><USER84> Apple pulling an A-Move straight out their jacket again. Haha anyone surprised? God, I lost my faith in this company a long time ago.

</comment><comment><USER85> Here's where this hurts. The Adobe blog stated that you'd be able to build iPhone apps.

It wasn't until recently that some of us stopped and thought, wait.... what if Apple decides to deny all Flash built apps???

A lot of time was probably lost by developers. There's going to be a lot of crushed dreams.

Plus, instead of spending $600 on CS5, I'll probably buy a Mac Mini.

</comment><comment><USER86> Don't forget another possible explanation: Objective C, C and C++ are difficult languages, meaning there's a barrier to entry. Apple may also want to prevent application development from becoming a commodity: they don't want "widget shops" employing warm bodies to churn out low-value applications.

Of course, I disagree with this approach: there already _are_ widget shops. It's possible to program in a language without knowing it, by writing it non- idiomatically resulting in buggier, slower code that takes longer to develop and is difficult to maintain. The fact that they write in languages that take longer to develop an app in would just mean they'll choose "low quality" while still maintaining the same quantity.

</comment><comment><USER25> Problems with it aside, and I certainly don't like it anymore then anyone else here (I was still hoping to get a lisp working for iPhone development), I think it would be wrong to attribute the decision to malice.

Apple's doing this for the exact same reason they do EVERYTHING else controversial that they do on iPhone OS: because the primary (only?) thing they care about is the end user experience being as good as possible. In this case, Flash (which I'm sure this is entirely aimed at) doesn't provide as good of a user experience as the native UI controls, so they're nixing it while they can without as much bad publicity as they'd have if they waited until after CS5 was released.

<comment><USER33> No, they're clearly doing this to lock people down and prevent strong innovation on their platform. They want tons of toy apps, but nothing threatening. They don't want people abstracting over their platform. They are deliberately restricting developer freedom. If they wanted to avoid crap apps, they would just reject crap apps. They don't care about that. They want to prevent developers from innovating on top of them, so they cripple the tools that developers may use, hobbling us so that we may only produce small cute toys which they can use to promote their platform.

<comment><USER25> Really? Bullshit. You honestly believe that stuff made in Obj-C can only be a toy whereas something written in _ActionScript_ will bring the "strong innovation"? Yes, they're certainly restricting developer freedom (which, again, I don't like any more then anyone else), for the same reason they have been in the past: because they don't want their _users_ to have a shitty experience.

I mean, how the hell do you define a "cute toy" vs. an actually innovative app? What's something that is more innovative on Android, say, or a Pre that isn't there on an iPhone? (Google Voice being the obvious exception, but again with the everything-Apple-does-is-about-UX thing.)

<comment><USER87> Tumult's point is not about writing a single script-based solution but rather about developing an enabling technology for a whole raft of solutions. A platform-on-platform.

<comment><USER25> Even granted that, the reason Apple doesn't want that is _still_ because of the UX. Apps with the same codebase for Android/iPhone will automatically suck as far as the UI is concerned. Things like the lack of multitouch gestures on android, different screen sizes, &c. Certainly has never worked well on desktop platforms... see: Java UI toolkits, QT (which looks fairly native but tends to _feel_ very wrong), Adobe Air, &c.

<comment><USER33> Who cares what you think they want? Read the developer agreement. What's it say? Anything that isn't C, C++, or Objective-C is banned.

<comment><USER25> Yup. And your point is? For the third time now, my point isn't that this is a good thing, and I'm certainly not a fan of the decision. My point is that Apple isn't doing this because they hate developers, or want to tweak Adobe's nose (well, maybe a little), but because all they care about is their product's user experience.

<comment><USER33> Why does it matter what language I used to develop an application, if it produces a binary that runs acceptably on the platform and otherwise follows all of the rules? I can write a more stable application in SML, Haskell or even untyped Scheme than most of the clowns I see making app store junk in Objective-C.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER88> "Apple responsible for 99.4% of mobile app sales in 2009"

[http://arstechnica.com/apple/news/2010/01/apple- responsible-...](http://arstechnica.com/apple/news/2010/01/apple-responsible- for-994-of-mobile-app-sales-in-2009.ars)

so obviously AppStore is a monopole - the other 3~10 stores have a miserable 0.6% ... of course that says a lot about Apple genius and how its competitors are plain retarded ... but ...

still i think they are more and more abusing their dominant position with their draconian dev rules ... and that should be looked at - could present some legal challenges for them ... im no lawyer - but i think the only way they can get away with it is tru the private nature of the dev agreement ...

incidentally - i really think Apple is special - one of a kind genius company - but also because of that people cut them way too much slack ...

to prove my point - just try this simple mental exercise - try to picture - what would happen on this same forum if we were discussing about say - Microsoft - say Microsoft just put out a nice new license for Windows-7 that said you "can develop for W7 only if you use C#, .NET, Microsoft own compilers, Flash is banned and Redmond will need to approve all any application" ...

dude - it's so funny i cannot even finish typing it ... really - it just sounds so crazy - like a story from another world - a world of evil monopolistic corporations that try to control our free lives... yet all we did with this simple exercise is to change one word : Apple -> Microsoft ... and - last time i checked - Windows does not even have 99.4% of the market - <USER3> like 90% coupled with a boring, inferior resource hogging product that though comes with all the freedoms democracy brigs us ...

and that proves my point - we do cut Apple way too much slack just because they are so awesome in making great products ...

full disclosure - i owned both iPhone 2G and 3G, just recently dumped 3G for a nexus-one because id rather own an imperfect (though rapidly improving) democracy than in a perfect nazional-socialistic system ... i still use my mac - osx is awesome and kicks Windows-7 lower-back ... and just got an iPad - just because there are no other choices ... yet ...

</comment><comment><USER89> You can't stop people from making their own choices, whenever you try to force any kind of sensor ship or prohibition on people, they will find out ways to go around. IMHO very stupid and arrogant move by Apple.

</comment><comment><USER90> Two things I haven't seen mentioned: 1. The majority of iPhone developers aren't effected by this at all. 2. To some degree, this is is about ensuring the Mac remains a required part of iPhone/iPad development.

</comment><comment><USER91> Bill Gates made a big mistake back in the late nineties. He could have just banned everything that didn't use the Windows API directly. Java and the web would never have happened. The world is so simple :-)

</comment><comment><USER92> My original reaction to this was "WTF. There should be a class action suit against Apple by developers along the lines of hindering freedom of speech".

... but then, any compiler that can generate the processor's instructions can obviously also be modified to generate Objective-C code. So I guess this will result in all the cross-compilers just changing their target language from llvm or assembly to ... Objective-C.

I can live with that ... and watch Apple slap themselves on their pretty foreheads ... whatever it is they hoped to accomplish in terms of lock-in :)

</comment><comment><USER93> Ok, idea: If we can't bring flash / other languages to the ip{{o,a}d,hone}, why not bring the ipod/ipad/iphone to other platforms? Write an Android wrapper around Cocoa's API, for example. Something like a WINE of sorts. People with lots of iphone app dev experience can write their iphone app, then turn around and recompile that Objective C code into an android app.

Far from ideal, but it may be the best solution at the moment.

</comment><comment><USER94> This doesn't sound practical for Apple to enforce - they could cherry pick a few big targets perhaps (Adobe....).

It could also simply be a change just so they can see what the response from the development community is - and may change rather soon.

I just can't fathom this particular rule lasting very long... it's not just lock-in, or a little bit evil, it's patently insane.

</comment><comment><USER75> Might sound ridiculous, but how would one write GLSL shaders now that the C/C++/Objective-C/JavaScript only rule is there...

</comment><comment><USER95> If the installed base of the products is large enough, no matter how draconian the terms there will be a subset of all potential developers that will be swayed by the money to be made so they'll accept the terms. Any attempt at boycotting will simply fail because of that.

</comment><comment><USER82> Apple is shifting the burden here from users to developers. It's easier for a developer to simply puke out a lowest common denominator app but it's not so good for the user who is buying the iPhone because of the cool UI/interaction/integration good native apps provide. It's easier for a developer to simply have their unmodified app run in the background but it's not so good for the user who is losing cycles/battery because of it. I don't want to justify it because obviously there's some valid downsides especially for developers to this approach. My only point would be that's Apple's secret sauce. It's gotta work right, it's gotta look right, everything has to work right together. Apple is going to do whatever it takes to make this happen because they feel like that's their core advantage over their competitors. They're probably right. If you disagree there's Android, BlackBerry, Palm, Nokia, etc. It's not like Apple has a gun to our head. As individuals we have free will.

</comment><comment><USER47> Adobe will not be happy about this, which makes me think: given how events unfolded recently in Adobe-Apple relationship and given that Photoshop is getting crappier and crappier in its OS X incarnation—has Apple some Photoshop/CS analog in the works?

<comment><USER96> <http://www.apple.com/aperture/>

<comment><USER47> That's a counterpart for Adobe Lightroom, not Photoshop. Of course I can plug a wonderful <http://pixelmator.com/> but as much as I love the work of fellow Lithuanians it ain't Photoshop yet :(

</comment></comment></comment><comment><USER97> This is only enforceable for tools like CS5 that reverse engineered the app signing process. How could Apple distinguish binaries produced intermediaries like PhoneGap and Appcelerator's Titanium from binaries produced by native Objective C code?

<comment><USER98> I'm sure it's possible to figure out if a programme was generated by some other programme. When programmes generate other source code, they will have a certain style, a certain naming convention for functions, a certain main class, etc.

</comment></comment><comment><USER99> Totally rational if: \- it doesn't undermine the market for Apple hardware \- it sets back competitors

The requirement to use Apple development tools, automatically means you must use Apple hardware to develop on. Ka-ching!

So, as an Apple shareholder, I'm happy about it.

</comment><comment><USER100> Apple has always been too rude to developers. Returning the iPad will be a good way to protest. Lets see how well apple does without early adopters (a major chunk of which are developers and developer referrals)

</comment><comment><USER101> I am not regretting my decision to move away from Apple and it's products.

The first thing that came to my mind when I read the title is "wtf". What a really bad move. I wonder how much more can the app developers take.

</comment><comment><USER102> I am not trying to defend Apple, but is it possible that the approval process was being slowed done by having to ensure that all the other intermediary translators were not using private APIs?

<comment><USER56> no, it isn't any harder to determine whether binaries produced by intermediaries access private apis.

</comment></comment><comment><USER20> Looks like <http://xmlvm.org/overview/> is still usable, isn't it? I am wondering when apple will close this route down, too, though

</comment><comment><USER99> I want to code in Objective-C, and I don't think Android allows that, so I'm stuck programming for iPhone/iPad. I wish Google will support Objectice-C calls against their APIs.

<comment><USER103> You could write your Android app in Objective-C and then run a program that translates it to Java. Google doesn't prohibit you from doing that.

</comment></comment><comment><USER104> Okay, there is ECL (Embeddable Common Lisp) which has been hacked up to work on the iPhone. It compiles to C.

I can't use it?

I hope there are other companies that will release usable tablet hardware.

<comment><USER12> I'm no Clojure fan, but if you want to write Lisp-like for a phone, why not Android? Your Clojure app can run on everything from the G1 to the Nexus One to the Archos 5" and 7" tablets, not to mention the wide variety of no-name Chinese tablets that run Android.

I've heard you can even get a SLIME/Swank REPL from the emulator or actual hardware. Seems like this beats the iPhone any day; better development cycle, and nobody can ever stop you from selling your app.

<comment><USER104> If I won't write for Apple, why should I write for Google (aka 'the NSA frontend') and their OS?

The only useful alternative will be a 'free' Linux derivative that does not restrict me in my developer choices and does not want to collect all kinds of data.

<comment><USER12> Android is completely Free Software. You can compile the git version and install it on pretty much any Android device. If there's spyware, delete it and recompile :)

And your less paranoid users can just grab your software from your website, and run it on their "stock" devices.

<comment><USER104> true, but I don't want to support a company that does not respect privacy and collects data without any control - I also don't have the time to inspect their code

<comment><USER12> So what's your solution, "do nothing"? Typical lisp programmer...

<comment><USER104> Lisp implementations like CLISP and ECL already run on various kinds of devices.

Sorry, that I don't care about running Clojure and/or Android.

</comment></comment></comment></comment></comment></comment></comment><comment><USER105> I'm no economist, and certainly no lawyer, but this does seem to me like it violates anti-trust law. Can anyone more informed about such issues comment on that?

</comment><comment><USER106> I suppose C++ will be banned when QT for iPhone is ready.

<comment><USER107> ROFL, as if Apple is going to allow Qt apps.

</comment></comment><comment><USER49> I think Apple could have done with some explanation on this, despite all the anti-compertative conspiracy theories, this has probably got more to do with weeding out apps that wont be able to multi-task on the new OS 4 platform, than being another salvo in an apple-adobe wars. Thats why the Rule change has been couched more in terms of how you can write apps (objective-c, api's etc), and not in terms of how you cant which is pure conjecture at the moment.

<comment><USER36> Sorry, I think you've failed to grasp what Apple's "Multitasking" is about. They are perfectly happy with apps that do not multitask AT ALL. They are not offering "true" multitasking, but allowing app's to notify system daemons to carry on CERTAIN tasks, e.g. IM notificiations, VoIP, downloading content. If an app doesn't want to do this, and there's no reason an App written in MonoTouch can't do this just as easily as an ObjC Cocoa app, that really doesn't matter to Apple.

</comment></comment><comment><USER108> Could this be something simpler like, code from non-XCode tools is more likely to hang-up their automated testing?

</comment><comment><USER109> Thought: They already reserve the right to reject an app for no reason at any time, why add this to the SDK terms?

</comment><comment><USER110> If I'm reading this clause right, it seems to prohibit Greenspunning (as a "compatibility layer.")

<comment><USER39> No, that was prohibited a long time ago.

</comment></comment><comment><USER111> isn't it possible to distribute apps written using other languages with this method ? [http://www.networkworld.com/news/2010/040810-apple-iphone- os...](http://www.networkworld.com/news/2010/040810-apple-iphone-os4.html)

</comment><comment><USER112> Compare this to the recent Google action of withdrawing from China, which company is evil? It's a no brainer.

</comment><comment><USER113> apple is too restrictive!

</comment><comment><USER114> I think this decision is also about preventing the virus and trojan hell like that on Windows platform and other "unauthorized" code to be spread on millions of devices. It is much easier and cheaper to examine and control such restricted binaries before releasing them on iTunes.

About Flash, Java and other outdated WM-based crap - they are pragmatic. They don't need any WM to run apps on their hardware. Modern CPU is the only necessary WM. So, there will be much less complains about crashes, bad performance and out-of-memory issues.

Together, these two major problems sank the reputation of Windows and Apple want to avoid them.

So, there is nothing special. Apple can dictate rules which helps them to make more profit, and of course they will.

Wanna freedom - there is Android. Google trying very hard to position it as Linux (community-driven open and free platform) for smartphones.

<comment><USER83> I don't know why you got voted down. I don't agree with Apple here, but you make a good point. However, assuming Apple is concerned about security here, it's clearly not the only issue.

Nanny Apple wants to dictate the media you take in. Trust me, if it could, it would restrict HTML. Open standards are only good if you control the standards. =)

</comment></comment><comment><USER115> And Microsoft just announced they silverlight can work on iPhone/iPad using IIS Media Services

[http://www.theregister.co.uk/2010/04/08/silverlight_media_se...](http://www.theregister.co.uk/2010/04/08/silverlight_media_server_ipad_iphone/)

<comment><USER25> That isn't silverlight, that's _video_ , which the silverlight media server now just provides in a format the iPhone/iPad already supports. No .net running on iPhone OS at all.

</comment></comment><comment><USER116> If you want to develop apps for the iPhone, iPod, or iPad, then you have two choices--make a webapp, or make a native app.

Don't want to learn Objective-C? Then build a webapp.

Apple is not restricting your rights. Apple is not stealing your freedoms. Apple is not being tyrannical. Apple is not snatching your children away as payment for your access to the AppStore. I bet there's very few on here who are even developing apps that are doing all the bitching. Your the I'm-a- Flash-developer I-can-has-AppStore? type who want to have access to the latest opportunity to grab some money bags without having to learn a new trick. Did you try to read a line of Obj-C and realize it has a different syntax than your Flash timeline and AS and decide to cry cos you might have to work for those riches you're after?

Do you all gripe that the web requires HTML? Did you all complain when Macromedia didn't give you Flash that only required you have a scant understanding of HTML and CSS to call yourself a "developer"? Your complaints are so lame.

Companies make products. They want to control their products and its image as much as they can because it is their livelihood. If you want to base your livelihood on that product, then you pay by their rules. If you want to be outside the rules then you go your own way, but don't start crying cos they ask you to use their product to make your money in a specified way that protects their name and image.

If you don't want to use the tools, make a web app. If you want to complain thAt web apps can't do everything a native app can, then learn the platform and make a native app.

Stop expecting that the company that has taken all of the risk and spent all the money on r&d and given you an SDK and documented it exhaustively and covers the costs of distribution and takes all that WORK and COST off your back is asking too much to request that you repay them with the kindness of protecting and advancing the brand by using the tools THEY BUILT FOR YOU so the product and the platform can stay popular and successful and keep making you money.

Good grief. That shit is so hard to swallow isn't it? Let's all burn our Macs and sound like morons with all our Android-or-Nothing cries while we quietly go fire up XCode so we can make some offing money.

This is stupid.</comment>