Why Apple Changed Section 3.3.1 | Hacker News Reader

Why Apple Changed Section 3.3.1

daringfireball.net

99 pointstumult104 comments

Gruber gets this mostly right, especially about vendor lock-in and abstracting on top of the platform as a whole (i.e. multiplatform, write-once apps.)

Where he gets it wrong is here:

IPHONE DEVELOPERS: No change. If you’re a developer and you’ve been following Apple’s advice, you will never even notice this rule. You’re already using Xcode, Objective-C, and WebKit. If you’re an iPhone developer and you are not following Apple’s advice, you’re going to get screwed eventually. If you are constitutionally opposed to developing for a platform where you’re expected to follow the advice of the platform vendor, the iPhone OS is not the platform for you. It never was. It never will be.

There are many good applications written in something other than C, Objective-C, C++ or JavaScript available for iPhone. In Apple's hubris to strike down Adobe and other opponents, they've caught many well-meaning developers in the crossfire. Especially in regards to independent and startup developers, being able to choose your tools -- tools that otherwise obey every other rule in the developer program -- is hugely important. I think most HN readers will resonate with this claim.

I can't stand Flash. I also don't much like plain JavaScript. I prefer to write applications in a mix of C, Scheme/Lisp, or Haskell. I can probably write faster and more stable iPhone apps with these tools than a 10-man-strong team can with C and Objective-C. I definitely cannot write faster and more stable iPhone apps with C and Objective-C than a 10-man-strong team can with C and Objective-C.

Apple's banning of languages other than "The Three Cs" strikes developers as egregious because we know how much the language you use affects how you think. Apple is telling us, now, how we should be thinking when we solve problems. They are asking us to agree to use only an approved set of thoughts.

They have a right to, it's their platform. We also have the right to walk away from this self-imposed kiddie pool, and go back to the ocean to ride the big waves.

There are many good applications written in something other than C, Objective-C, C++ or JavaScript available for iPhone.

Any examples? I'm genuinely curious since I've heard that a few times already today but haven't heard of any specific examples.

Anything with a parser. Anything that uses Quartz 2D (a drawing library that uses the C preprocessor, in Cocoa/UIKit.) Anything with C preprocessor macros above a certain unknown threshold (hey, Objective-C was originally just a bunch of macros!) Anything that implements its own memory management scheme. Probably 90% of non-trivial games, and 100% of the good ones. (Almost all good games utilize their own runtime implemented in either C++ or other fast language, abstracted into a higher level set of primitives for the game designers to work with.)

And you think Apple will institute a policy that kills off 100% of the good games on their platform?

They already did. Now they get to choose when to apply it, arbitrarily.

It appears that the lawyers want to, yes.

And why have you concluded that the clause is made by evil lawyers (who Apple hires) and not by the business? Can I really do anything I want in life, and if I'm criticized, I can just claim, "my lawyers made me do it"?

Quartz 2D is Apple's C-based graphics drawing framework, mentioning that is irrelevant here. I still haven't seen anything specifically mentioned that's not written in C. You mentioned using Lisp & Haskell to write iPhone apps, which ones are those? Who else is doing this and which apps have they published?

Quartz 2D is Apple's C-based graphics drawing framework, mentioning that is irrelevant here.

Quartz 2D is written in the C preprocessor language, not primarily C. To use it, you mostly use C preprocessor directives, not C. It's then translated into C by a compiler, before being compiled by the actual C compiler.

I still haven't seen anything specifically mentioned that's not written in C.

Other people have. Tons of applications, probably tens of thousands at the very least make direct use of some kind of abstraction tools. Hundreds of thousands (or all) if you take Apple's clause literally.

You mentioned using Lisp & Haskell to write iPhone apps, which ones are those?

I'm not obligated to tell you.

Who else is doing this and which apps have they published?

Is this a serious question?

You're making a lot of claims without citations. flyosity's absolutely correct to question them, and if you're serious about what you say, then yes, you are obligated to back them up in some way.

Citations: Quartz 2D: Read Apple's library docs or headers. Publicly available. No other devs have stepped up to question this claim. Dead obvious if you use it.

My own apps: I'm not obligated to tell you. If that pisses you off, sorry, then just ignore that part of my claim, I don't care.

Who else is doing this: Any game made with Unity. Any game made with Mono. Any game made with Lua. Any game made with its own runtime. Any game made with Python. Any game with an advanced preprocessor. Any game that manages its own memory.

Any software with a parser not written directly by hand with C arrays (i.e. any that are worth a shit.) Any software that uses C macros (all of them.) Any software that uses garbage collection. Any software that uses Core Data (violates their own rules.) Any software that has linked in a regex library.

Things that would not have been created had their creators had to work with the same limitations they now impose on others on their platform: every single part of their toolchain. Objective-C, graphics, the compilers, everything.

The C pre-processor is part of the C language definition.

A specific example: Canabalt (fresh take on the "platformer" genre)

Though the flash version of Canabalt is written in ActionScript 3, the iPhone version is written 100% in Objective-C. Take my word for it, I personally did the iPhone port.

Do you think you could have ported a non-trivial game with Objective-C? How about something like Braid, which is slightly less straightforward?

I don't think it necessarily matters how trivial the game is. If the game is more complex, then it is just a matter of requiring more time to do the port. Canabalt took just under two weeks to port. Something like Braid would likely take significantly longer.

I was unaware of that. From what I gleaned using class-dump, it appeared that you were using a custom version of flixel that retargeted Objective-C. My mistake.

(also, nicely done. the iPhone port is very slick)

If Microsoft said "No Windows 7 Mobile apps that aren't C++ or C#" we'd just shrug, and say, "well, that's Microsoft for you."

Microsoft would never do this. They are the "developers, developers, developers" company, after all. They even invest money in programming language research and actually make the academic stuff production capable.

Apple just adds half-baked features to dead languages. "Yay."

You're right, but I had already removed that paragraph before you commented.

I prefer to write applications in a mix of C, Scheme/Lisp, or Haskell. I can probably write faster and more stable iPhone apps with these tools than a 10-man-strong team can with C and Objective-C.

Have you?

Yes.

We should just take your word for it?

If you don't want to, you can just ignore my comment.

Can you probably, or have you actually build in shorter time (or did you really mean apps that run faster) apps that are more stable than that created by a 10-man strong Obj-C team for the iPhone?

If so, would you say it was a function of the quality of the other programmers, or could it be distilled to purely tools?

Genuine interest (since I love languages for their own sake and the expressiveness they allow): what tools + languages did you use?

iPhone developers: No change. If you’re a developer and you’ve been following Apple’s advice, you will never even notice this rule.

This is where he goes wrong. Using multiple layers of abstraction has always been a win for programmers, and not just for compatibility across platforms.

This move by Apple is equivalent to IBM saying in 1970 that programmers couldn't use high level languages-- that they had to write programs only in IBM 360 machine language. The loss would not have been only in portability.

> The loss would not have been only in portability.

I think their loss is about to be in the form of an exodus of developers.

Is that true? I sure hope it is, but I wouldn't count on it. The vast majority of developers have been working in straight Objective-C anyway.

Plus, they have so many apps, even if they lose a lot of their high-quality developers, that'll probably just be a tiny blip when it comes to total apps being submitted. It might take a long time to notice that the quality of apps has gone down, since it's so hard to quantify, and there no doubt will still be some quality apps. And them noticing quickly is what we need so that they'll reverse this rule.

I'm not sure that the "quality" of the majority of the apps in the app store is very high anyway. There are certainly high quality apps, and I'd bet dollars to donuts that they are written in one of the approved languages.

But the reason the iPhone became popular is not because there was a very high quality app version of wolfram alpha or a gold game, but because there were reasonably good quality apps (at a good price) that scratched relatively small, (dare I say it?) long tail, itches.

You can be relatively sure as a new iPhone owner that you'll be able to find your fishing lure guide app, or your app to order emergency socks or whatever. I'm willing to bet that lots of those apps were not written in one of the approved national languages of the Union of Soviet Apple Orchards.

"Plus, they have so many apps, even if they lose a lot of their high-quality developers, that'll probably just be a tiny blip when it comes to total apps being submitted. "

This was true when an exodus from Windows started. Windows still has a lot of committed talented developers, but it is also true that a lot of developers moved away from Windows and it hurt them long term.

"It might take a long time to notice that the quality of apps has gone down, since it's so hard to quantify, and there no doubt will still be some quality apps. And them noticing quickly is what we need so that they'll reverse this rule."

I personally would hope that Apple does not change this rule for years (and add more dickhead rules) till a more open/dev friendly competitor has sucked up all the devs who move away and achieves critical mass.

Don't distract your opponents (and evil people in general) when they are doing something stupid.

The highest quality apps in the App Store are being written using Xcode & C/Objective-C. The biggest app development shops working on the biggest and most popular iPhone apps are using Objective-C and Cocoa frameworks, not any kind of meta-platform. Users won't see any loss of quality, none whatsoever.

There are hundreds of games in the App Store built with Unity, including at least one in top 10.

You can be sure that if Unity games are taken out of the app store, people will notice.

Which just shows that some people go to great lengths to explain Apple's anti-competitive behavior ... "it's OK, it doesn't affect me" ... maybe not in the short term.

It's certainly true of one developer .. I'm a C# developer who was about to buy a Macbook Pro specifically so I could target/port an app to run on iPhone (was just waiting on the refresh). This is the last straw as far as I'm concerned...

So yes, one less developer for iPhone (except as a web platform, if they are lucky). Also one less MacBook pro sale for Apple (probably, because I'm so steamed about this.. though .. heh, maybe lets see how the refresh looks next week and then we'll see)

I think their loss will be in the mass of flash developers who will now be developing for android.

CS5 also targets android.

That's a nice pipe dream, but nope.

Checks yesterday's sales

Nope, we're good.

You're being overly dramatic. This has nothing to do with the normal use of layers of abstraction in your in architecture.

> This has nothing to do with the normal use of layers of abstraction in your in architecture.

What's your definition of 'normal'?

What if you abstract out your logic with a DSL that compiles down to iPhone native code? This is in violation of their terms of service.

What if your DSL just generates C code? That also looks like a terms of service violation.

Now what if that DSL is a yacc grammar for a network protocol or configuration file? Not an abnormal use anymore, is it?

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage.

And that makes Apple evil. At least, it does in the sense that Google uses the term in "don't be evil" - I believe pg translated "evil" as something along the lines of "trying to compete by means other than making the best product and marketing it honestly".

Not to mention stupid - has a cross platform framework ever become a de facto standard?

And the point about the quality of apps generated is complete bullshit and he should be ashamed of saying it. The quality of Unity3D and other frameworks is probably above the average for the App Store. In fact the whole point of these frameworks is making generating higher quality programs easier.

What really pisses me off with Gruber's post is in defending the indefensible he's making it harder for Apple to realise that this is a mistake and correct it.

Apple should really just have said what they really want - you can't put anything in the App Store if its available for another platform. The problem being they don't want to exclude the big players, so they just make it hard and unpleasant for the little developers, yet again.

Edit: I mean cross platform application frameworks. Of course there are cross platform things have become de facto standards.

Didn't flash become a defacto standard?

That's a pretty big stretch. Its a standard because it allows people to do things in web browsers that they can't do otherwise. Any cross platform framework can only offer a subset of features to the developer through native toolkits. And any non-cross platform framework will always be at the hardware developers mercy. Apple is completely mistaken to be threatened by frameworks.

How is Flash a big stretch? As a cross-platform framework or as a de facto standard? Basically Flash was quickly becoming de facto way to access features that browsers couldn't access, it was a serious threat to every platform vendor, making OS commodity. HTML5 is catching up with Flash, but ain't yet there + there is inconsistency problem due to multiple browser implementations.

Its a stretch to say its a framework, or at least it is in the context in which I meant framework. But I didn't make that clear and it seems to be too late now. For the record I think crossplatform application frameworks are unlikely to ever become de facto standards because they generally use a subset of features of the platform and non-native widgets. In fact that's Gruber's problem with them in the article - but he ignores that that should make them nothing for Apple to fear.

I totally agree that cross-platform app frameworks never become de facto standards, because adding an extra layer of abstraction between native UI widget APIs usually dumbs down the user experience.

However, cross-platform frameworks that don't try to replicate platform's native UI experience, have been and are successful, mainly in games. And Flash can be seen as a one and by far the most succesful contender in that space. After HTML/JS that's it.

> has a cross platform framework ever become a de facto standard?

Does html count? Posix? It could definitely happen.

I wouldn't consider HTML, a presentation markup language, a (programming) framework.

Yeah, I was typing on a phone. I meant HTML + JS + browser DOM + CSS + etc.

Posix isn't a bad example, but I still think it incredibly unlikely that frameworks at the application/gui level are going to become standards in place of Apple's APIs.

Instituting a blanket ban on all frameworks (regardless of crossplatform status - which 3.3.1 doesn't mention) and restricting languages for fear of being displaced is ludicrous. Even if Apple's fear was legitimate there are plenty of other measures they could take if this problem actually occurs.

Whatever Apple's intentions this wording is a mistake and they need to revisit it. Good frameworks that make the App Store better are going to be pushed out by this.

Renderware and Unreal Engine both spring to mind.

Renderware made every cross platform game made in the PS2/Gamecube/Xbox generation look like garbage because the PS2 ended up being the lead SKU.

I am in no way defending the change to 3.3.1 though, I think it's bullshit.

Though it didn't become 'standard', the cross-platform aspect of Java's AWT/Swing APIs definitely gave it an early boost in uptake. I would also agree with the inevitable disagreement, that Java truly found its niche server-side (cross-platform support probably helped there too).

That's exactly what Apple is trying to avoid- AWT/Swing UIs never felt native, because they had to work everywhere. They couldn't use any native OS features.

As a developer, I'd LOVE to write-once, compile everywhere, and be done, but as a user, I know that creates terribly inferior product.

And who is Apple competing with? Aren't they in the business of selling consumer computing devices to end-users, including hardware to developers who create stuff for their platform?

i.e. it is rational for them to optimize the number of Apple products get used.

This reads like an apology for posting his previous blog entry about Section 3.3.1.

He's wrong about MonoTouch; It lets you code in the .NET language, yes, but it still targets the iPhone APIs. By the same logic, they should ban C and C++ because you can write iPhone applications and Windows applications in it.

He says "Adobe’s goal isn’t to help developers write iPhone apps" which is just silly. Adobe's customers are developers and it's in their best interest to help their customers make iPhone apps. Their technology is Flash so that's how they do it. It's really Apple that doesn't want to help developers by restricting their choices.

That's Objective C and C++. You can't program in those for Windows, they are pretty much Apple languages despite things like gnustep.

You can't program in C++ for Windows? What in the world am I doing with all these Visual C++ books, then?

"Objective C and C++" is "Objective C and Objective C++".

If you are constitutionally opposed to developing for a platform where you’re expected to follow the advice of the platform vendor, the iPhone OS is not the platform for you. It never was. It never will be.

Good lord, advice? He's making it sound as if it were some conventional programming suggestions on how to avoid buffer overflows.

> "On the one side, this rule should be good for quality. Cross-platform software toolkits have never ever produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS."

This is a silly thing to say. From what I've seen of MonoTouch the UI looks like the same Apple chrome to me. Unity seems like a good choice for gaming and most of the games look great.

The best counter to the quality argument I've seen is a comment on the Appcelerator blog:

The irony here is that Titanium apps are fully native and make use of iPhone-only features, and they’ll be rejected. Alternatively, you could open up a web view in Objective-C, and pop whatever slow, non-native crap you wanted in there, and not be in contravention of the rules!

http://developer.appcelerator.com/blog/2010/04/iphone-os-4-0...

Is Gruber a programmer?

I don't see how the user experience would be different for an app written in Haskell versus an app written in Objective-C, except that the Haskell app will run faster and crash less (in general). "Platforms" have nothing to do with it; programming languages are just a way to convince the CPU to do stuff for you without telling it about every memory load.

Yes, he wrote Markdown. http://daringfireball.net/projects/markdown/

Oh yeah. Good choice of programming language, too :)

Anyway, it's scary to watch the Reality Distortion Field affect otherwise rational people, like Gruber. Perhaps I just misread.

Has he ever been rational w.r.t. Apple? Maybe it's a recent thing and I have a poor memory, but I seem to recall him always being a fanboy (not that there's anything wrong with that).

He's never been rational, but that irrationality generally expressed itself as biting critiques of minor aesthetic and usability issues that Apple was mucking up.

He's let himself be thoroughly trolled by all the gadget blogs that alternate between calling the iPhone the best/worst thing that's ever happened in search of pageviews and as a result became very defensive and self-righteous lately. The world has been divided into those who "get" and those who don't "get" the iPad.

Right. Sometimes I get very annoyed at his posts for being one-sided, but it's only me to blame: it's his blog and I'm just visiting it.

Markdown.pl is one of the worst small programs I have ever read, with well over a hundred outright bugs and misfeatures that continually bite its users in the ass. It's dogshit even by the already low standards of hand-written many-pass regex-based spaghetti-parsers.

Nobody should be using the original script, and unfortunately many of the other implementations out there are direct transliterations that copy all of its absurd bugs, like where if you mention the MD5 hash of another token in the document, the hash will be replaced with the token, because it uses that as an inline escaping mechanism!

See the changelog for what started as a PHP transliteration and turned into a rewrite that squashed 123 (!) unacknowledged bugs: http://michelf.com/projects/php-markdown/

The worst part is that he outright refuses to either disclaim or fix his implementation, and he's repudiated everyone else's attempts to do so. He's a terrible programmer, and a worse maintainer. I'm not saying he should be forced to steward a community, but barring that he should at least have the decency to take it out back and shoot it.

  Is Gruber a programmer?

Why would it matter?

  I don't see how the user experience would be
  different for an app written in Haskell versus
  an app written in Objective-C, except that the
  Haskell app will run faster and crash less
 (in general)

I assume you wrote some apps for iPhone and did some benchmarking, right?

  "Platforms" have nothing to do with it

This is where you are really wrong. Platforms and cross-platform development makes are huge difference in user experience. Take Android: if you try to target as many devices as possible you aim at the lowest common denominator. That means that more capable devices will provides lesser experience than they are capable of. Now if your tool allows to target Andorid and iPhone it gets even worse. Gruber's example with Kindle apps is spot on, it's ugliest app for Mac I've ever used.

I was about to ask you for proof that Haskell is faster and crashes less, but then I saw who posted.

How are those as-fast-as-C Python networking scripts built around epoll coming along?

I think that his digs about user experience are based on UI toolkits and following all the Apple interface rules and conventions. His example at the end of the post is the desktop version of Amazon Kindle (bad, because it uses the QT toolkit and its buttons don't line up in an Apple-approved way) versus the iPhone version of Kindle (good because it's "a native iPhone app, written in Cocoa Touch").

It's a pretty standard line: Apple does it better by scrupulously maintaining identity of interface design and conventions; Linux or Android or Windows is less good because there's so much more variety (visually and in terms of what buttons do what). (Please note: I'm describing a common argument, not taking sides on it one way or another.)

So in that sense, he's not really talking about programming languages so much as UI toolkits and I suppose the conventions that go with them. If there were a way to turn Haskell code into a perfectly Cocoa UI, he might very well like it fine. Though, actually, in my experience, he usually finds a way to side with Apple no matter what else is the case...

"Web Developers: No change." Not so. I'm a web developer, and I was just getting into iPhone development via Appcelerator, which has no future under this developer agreement.

> "Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage."

That is true, but not all of it - if Apple allowed code generators there would be a glut of cross-platform apps being written in this middleware as developers try to write-once for multiple platforms (Android, BB, etc).

With this you will also see apps that do not follow Apple's HCI guidelines, eschewing Apple's aesthetic and workflow standards for lowest-common-denominator cross-platform UI. This would be a death blow to Apple's platform, since its primary advantage is having better UI than everyone else (this includes 3rd party apps).

IMHO this is more frightening to Apple's continued dominance than simple tools/language lock-in. If you didn't like Obj-C, Apple is not terribly pained to see you use something else... but if you bring Android-calibre UI onto Apple's platform Steve will be very sad.

"if Apple allowed code generators there would be a glut of cross-platform apps being written in this middleware as developers try to write-once for multiple platforms (Android, BB, etc).

With this you will also see apps that do not follow Apple's HCI guidelines, "

Good points but do they really matter as long as Apple controls the AppleStore ? It is not as if anyone can sell or deploy these without Apple's approval. I am not disputing your larger point (which is a good one), but how would an app that broke the HCI guidelines (say) get approved? Do such apps get approved today?

There are enough ugly apps on the app store that I find this argument unconvincing even if you accept the premise that this is reasonably Apple's job rather than customers choosing what to buy.

Gruber is very wrong in thinking that languages other than Objective-C, C and C++ inherently generate non-native apps. Other languages can simply link to the native libraries and still use native widgets - that is if this wasn't specifically forbidden by these changes. So clearly this is about something else.

Apple could simply use its approval process to block apps if they started using non-native widgets anyway, and that wouldn't be contrary to its current HIG.

I'll wait for Apple to provide their own explanation.

But it goes without saying that Cocoa and Objective-C are still small potatoes compared to Flash and C#/.NET, despite the iPhone's recent popularity with developers. Platforms are always competing for developers, so it shouldn't surprise anyone that Apple would take steps to protect the viability of their development platform.

Gruber's a pretty good apologist.

He completely failed to acknowledge a big issue for developers and users of other mobile platforms. They miss out on apps in a world where there is a leading platform in a monopoly position, and nobody can use cross-platform toolkits to develop for that platform. (I don't know why Gruber was compelled to invent the term "meta-platform", but oh well.) Ask any Linux or OS X user - except Gruber apparently; non-native apps might suck, but they are better than nothing if they're the only one of their class on your platform. Most people prefer native apps on any platform, that's why Apple had to change Safari on Windows to better match the Windows look & feel. But if Safari were the only web browser for your platform you would use it no matter what. Even with cross-platform toolkits we Linux & OS X folks don't get quite the # of apps there are for Windows (unix software doesn't count for most people ;-).

I'm apologise in advance as I strongly dislike the term, but Gruber is a fanboy. You have to keep that in mind and know to bring a sack of salt to daringfireball.net. That said he gets enough right on the money to keep reading. Just don't forget the salt!

"I’m not arguing that it’s anything other than ruthless competitiveness."

Seems more like an explanation of their motivations rather than a defense.

Not to be a Gruber apologist.

Who exactly required an explanation? We all know it was intended to mess with the competition.

And if your explanation includes claiming, falsely, that all those affected were producing shitty apps then that's not an being an explainer, it's being an apologist.

I am very confused with all of the rhetoric going around. His post was one of the more substantial explanations I've seen on HN. (And of course, the resulting comment thread here is usually very helpful in parsing this kind of debate.) "We all know it was intended to mess with the competition" -- sure; but you wouldn't be here if you didn't want to go more in depth.

As I read this I get the strong feeling that Apple can do no wrong - whatever they do, they'll be a strong apologetic exegesis from the Apple-ites to justify it somehow, even if it requires some pretty awkward contortions.

Once you have fans, they'll instinctively defend you. That doesn't mean you can't lose your fans.

Isn't that point completely meaningless? You're not submitting the source code, but the binary to the store. They cannot know what language you used without doing some fuzzy binary-fingerprint matching to detect parts of runtime etc. If you're clever enough and think that "time to hide the fact I'm writing in C#" << "time needed to rewrite the software in obj-c", you can just scramble the binary and hope they won't ask why you did it. They cannot prove what compiler or language you used.

Those were my thoughts as well, how can they know if you cross-compiled?

It's trivially easy to tell. If it doesn't look like right, they can simply hold your app in the queue until you prove otherwise. Being sneaky in this scenario probably isn't a good idea -- Apple holds all the cards.

And there's a possibility that you as a developer might be banned by Apple.

Yeah, but you agreed to a contract, and their license, which says not to do it.

Let's get real, developers aren't going to flee from iPhone because of some draconian framework / compatibility measure.

Just like they didn't flee because of restrictions on which Apps got into the app store. Certainly no one liked it, but they kept writing apps just the same.

The iPhone has sexiness and installs on it's side, that will keep the vast majority of programmers chugging away at C / C++ / Objective-C despite their misgivings.

I sincerely hope that's not the case, but I fear it might be.

Why not write a native Obsessive-C application which is a Java, AS, Python or whatever Virtual Machine ?

On the other hand, when I develop with Flash CS5 I don't download iPhone SDK and read no License.

Here: http://news.ycombinator.com/item?id=1252428

Could the same legal argument, in some way, be applied to the new section 3.3.1 of the iPhone Developer Program License Agreement(iDPLA)? Someone with a legal expertise could say something about the matter? If I'm not wrong the iDPLA is a American contract, and also it's not an electronic device, so I'm confused.

This is a real question, I do not want to criticize or praise Apple or the iPhone or whatever else.

Why should we, as developers, be happy that Apple is creating lock in? Sure, I understand why, but does that mean we should all just accept it? Was the Microsoft era something we all look back fondly on? I think you'd have to be a complete fan boy to have that much vested interest in Apple's success, without actual equity in the company. Clearly it is better to release your apps on all platforms with as little effort as possible.

People - relax. The cross-compiler vendors will simply change their target language from machine instructions to .... Objective-C. It's probably a much easier target anyway.

Read again -- it says you must write the application, originally, in Objective-C, C, C++, or JavaScript.

But if the compiler generates "readable code", there is no way to counter my claim that I "wrote" my program in Objective-C.

If that is indeed Apple's instruction and what developers need to abide by, lets lobby the processor manufacturers to mandate that apps for their processor must be "written" in their assembly.

There is probably no good technical way for them to counter your claim that you wrote it, but you would be lying, and you agreed to their contract+license which says you won't do it.

I absolutely don't think I'm lying when I say "I wrote program B" (from my second argument). It hinges on what "write" means. It no longer means "put pen to paper". If that's true, then nobody "writes" software any more and all developers are liars when they say "they write code". Then what does it mean? "Create" is closer to it.

Also if "you" as a company hire someone to "write" an iPhone app which you submit to Apple, then technically you didn't "write" it either.

Any physical interpretation of "write" doesn't work. Even if they changed it to "type", I can generate program B and literally retype it into the computer to satisfy the legality.

In simpler words, the requirement seems just plain stupid and invalid to me. Fire the lawyers who "wrote" that :)

I believe the appropriate term that would come into a proper definition would involve mechanical translation. Those parts that are input into a process of mechanical translation, but are not themselves a product of mechanical translation but rather in substance the product of human agency, are original source files.

But the contract term as it currently reads certainly seems sloppy.

Not sure if even your "mechanical translation" condition works, though certainly tighter.

What if I hire a human to do the translation? If even that would violate the agreement, then the "original written language" of every program is the plain language specification document (that is, if you write one).

Heck, XCode has project templates that "write" starter code for you. So, technically, no iPhone developer "wrote" every single line of copyrighted code.

.. and (someone else mentioned) copy pasted public domain code, apps ported from other platforms, are all ruled out.

Basically, it seems that this clause reeks of a lack of understanding of the nature of software.

If push came to shove, I think giving them access to your github repository and its commit history would prove things.

"Nice github repository. It looks like you were right. That's nice. Your app has been rejected anyway. Because we feel like it."

Another argument against the validity of that requirement - if I write a program A that writes another program B, can I not claim copyright for program B? If not, then an artist using Adobe Photoshop cannot claim copyright for their PDF images because PDF is a "program" that their work generated that is "executed" by the Postscript runtime. (In that case, they didn't even write Photoshop to start with.) So if program B's copyright is mine, then, legally, I "wrote" it.

Copyright law has nothing to do with this requirement. If Apple thinks you originally wrote your program in another language, they'll remove it from the App Store. If you sue them for this action, you'll have to prove that Apple somehow broke their agreement with you. At the minimum, you'd have to prove that you wrote the [Objective] C[++] code yourself. My understanding is that the agreement allows Apple to reject apps for any reason they want, so even if you manage to convince a judge of the pure pedigree of your code, you've gained nothing.

The moral of the story is, "Don't work with assholes when it can be avoided."

Copyright law looks like the only reference point for defining "write" - if you own copyright for something, you "wrote" it, otherwise you legally didn't (even if you claim otherwise). It might have been much simpler if Apple just said "all applications should be products of the iPhone SDK tools".

Anyway, it all depends on what exactly they want to accomplish with this clause and it is poorly worded at the moment for whatever that purpose be. Hope Apple clarifies soon.

Reply on news.ycombinator.com