@Lawrence, that’s exactly what Unity3D does, and no, that’s not a way around 3.3.1, which explicitly forbids that because the game was “originally written” in a language other than C/C++/Objective-C. Plus, if this were OK, Adobe would be able to use this technique to get their stuff on the iPhone, which seems to be exactly the scenario 3.3.1 was designed to block.

Regarding Firefox, I actually prefer how Firefox does copy/paste: http://cl.ly/Hws

For me, Firefox’s main shortcoming is that copying rich text from it doesn’t work well, where Safari is very good. I have a habit of saving snippets from websites and prefer their original formatting.

I can hear when my wife is onto farmville because the fan of her computer is running high. How come such simple functionality uses so much power?

Please, use my battery with care.

I think much of the response seen above come from seasoned developers protecting their personal investments.

Modern devices should not be burdened with old paradigms. New developers should not be led to follow older colleagues bad habits.

On the same note, objective-c is of course not necessarily the final point of computer languages. The point worth attention is, how to promote battery saving and developer friendly coding practices.

Address that and you will surely get Apples positive attention.

Although I am not a big apple fan, i am a developer. And for apple to cut me of tools such as mono for cross platform dev is completely absurd.

Why should i rewrite all the libs that already exist and add thousands of lines of untested code if there is already tested and widely used libs for it.

Simply don’t see any of devs who have extensive experience to switch to strictly iphone dev if it is easier to develop for symbian, Maemo, android and palm with cross platform tool (write once, …).

Oh and btw: Nokia found the hard way that closing your platform is bad for business. Once a giant nobody could touch is now abandoning Symbian for Maemo on smart phones …
As for google goes: If it wasn’t for the privacy issues it would be a model, how to be a company. It helps developers not only with opening code to its platforms, but also by publishing libs that help development. And as my vote goes it wins over apples “Mine … all mine’ attitude. Even if they have the prettiest of phones.

(google fan )

Lastly, what about:

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

Does this mean we can no longer call Facebook, Twitter, or Google API’s? What about calling my own API in my cloud that allows me to get data back for my custom app?

Apple has really messed up here.

Certainly terrible for Flash (cross compiler approach). I do think many people are reading into this way to much. This does not prevent game middle ware such as Unity. Unity creates a xCode project to be compiled by the apple tool chain. The scripts are compiled to ARM assembly and do not link against the Coca libraries as far as I am aware. They are only for controlling the game engine. I would imagine every major game studio does the same (no embedded scripting allowed).

The 3.3.1 article in question states ‘originally written’. This does not imply nor does it explicitly state a human had to write the code. If that were the case then you could not use xCode or IB to write code for the iPhone. Translators and generators at the source code level are fine. The input to these tools is irrelevant. You are free to use whatever language you wish to compile to ARM assembly for use in your own code. You can not however link against the frameworks. You can use C# to write algorithms, compile using GCC/LLVM to object code and then link this object file in your final executable. No issues.

What they are preventing is intermediaries. They are preventing tools/middleware from acting as an intermediary during the compilation process of languages other then the ones specified. This is the reason for the term ‘link’ and the clarification that follows this sentence.

If anything apple need to specifically state the terms in language that is far from interpretive.

http://www.readwriteweb.com/archives/flash_now_importable_to_hmtl_canvas.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29

Notice that this too is banned by 3.3.1 . Flash/Actionscript dialect is being translated by into HTML5/Javascript by the Adobe tools (not at run time but prior to deployment). It is being written but doesn’t originate in Apple specific Javascript.
Sure Adobe is also pushing the Flash translation/glue adaptor (and are taking opportunity in associated video to so that performance is actually better), but that isn’t sole translation they are supporting.

The developer has a set of choices on how to deploy the simulation in the video. There are different tradeoffs for each one. In some cases that translation may be applicable and in others not. The terms of a SDK contract is a rather curious place to resolve those tradeoffs.

“Applications must be originally written in …”

to

“Applications must be innovatively written in …”

To see what getting at on a Mac go to the dictionary app and look up the word “originally”. There are two connotations of that a word. The first is the identify the origin of something. The second is to be novel or innovative.

That is what the core issue of the real debate should be about. Whether to follow a restrictive, narrow path to applications or a novel and innovative path.

From the example cited later in 3.3.1 it seems likely that Apple wants to choose the first meaning. As Gruber’s article points out this is at the core issue about vendor lock in. (not quality user experience, vendor lock in. Developers much narrowly follow Apple’s path no matter what they choose to do. )

Note that this restriction bans not only Flash but utilizing assembler for any critical section of code. It bans both faster and slower approaches the construction of and execution speed of apps. That is primarily because it is about restricting the origins of the apps rather than any quality goal. Almost all of the hand waving about quality lapses into subjective judgments on narrow subareas of user experience.

If the application is developed using a slightly different language with some syntactic sugar that is more oriented to the problem domain than raw Obj-C/C/C++ are then what is the hang up if the syntactic different is pre-compiled into Obj-C/C and an application is built ? There is no difference.

Second, this is even somewhat hypocritical on Apple’s part. Two examples.

1. XCode tools UML code generation abilities. Apple itself builds tool to take elements of a program written in a representation that supports better long term maintainability and automatically generate code from that. There is zero reason to keep software development in the stone age where the sole valid representation of the development is text in some file. For substantive elements of many application text isn’t necessarily the best long term representation of the application that provides the clearest representation to the developer.
[ In the Gold Rush , "throw away" AppStore perhaps that is a secondary issue. ]

2. iTunes and Safari on Windows. If Apple is so dedicated to its core on user experience how come those aren’t rewritten from scratch, pure Windows user experiences ?

Organizations that have very large code bases to port typically can’t afford to start over from scratch to built a very that is a a port. They will typically use some combination of tools or techniques to bring over the bulk of the application between platforms.

For example, a Flash to Javascript/HTML5 translator could perhaps do 50-90% of the translation leaving just the remaining percentage to be manually translated.
ActionScript 3 is a dialect of EMCAScript (http://en.wikipedia.org/wiki/ActionScrip_3). So is Javascript. Related in a similar what to how Obj-C is to C. What Apple has done here is ban anyone who wanted to do a port but try to reuse the maximum practical amount of code.

Adobe was doing something different. I suspect they were compiling straight to binary so they’d still be banned with the change. However, there were other tools that were trying to do things the right way. Apple banned them to by focusing more so on being an obstructive than fostering innovation in doing things the “right” way.

So when folks howl about Adobe being slow to 64-bit ( even after Apple canceled Carbon-64 after stating they would do it. This also follow 68K to PPC transition and Mac OS 9 to Mac OS X transition which all had associated migration costs.). The thought experiement should be if you were given a code base of 3-6 million lines of code and told to port from one API to a new incompatible one how would you do it.
Would how long the code base been in existence have any impact on your decision ( 2 year old app versus a 8 year old app. ) ?

Finally, Meta framework often fail because they are too broad. A framework for any and all applications will have problems. That is not necesarily true if you narrow the scope. If aim the framework at multiplatform word processing apps or multiplatform IM app then the constraints on GUI concepts can become tight enough that can compose in an abstract RAD environment and generate very close to native representations. Again Apple has thrown that out the window because tools can’t be utilized to compose applications.

Apple doesn’t care because just want vendor lock-in. Squashing innovative approaches to composing apps isn’t their problem. The AppStore has too many apps. They really don’t need any more to make lots of money so they are taking the calculating step to squash an even higher rate of growth which happens to also negatively impact their competitors.

P.S. The timeliness of porting programming frameworks isn’t a problem if the framework developers are clued in eariler in the process. Similar to how the Wall Street Journal got iPads when the rest of the vast developer base was stuck with a not quite so accurate simulator.

In the iPhoneOS 4 demos the developers said most of the changes were localized and took hours/days to make the changes. It isn’t like Apple would have to release info under NDA months in advance. If the tentpole changes are present in the commonly generated code by the tool then the next build will easily pick them up.

In short there really are very few technical issues here that block good, high quality apps here given that the tool makers are just as dedicated to app quality as the developers who use them are.

This is primarily a power, money move on Apple’s part.