Apple answer to devs, Adobe and Google

Posted: April 10, 2010 in IT/Dev
Tags: , , , , , , , ,

Since the starting of the crisi between Apple and Google (whose Android and more recently Nexus – in contradiction with their implicit non-competing agreements -, leaded to Apple being angry – what is understandable considering Google was among its board of directors these lastest 3 years-, and to an indirect threat through sueing HTC about Apple’s patents), and more recently Google’s help provided to Adobe (integration of Flash into Chrome – that is the opposite of Google’s commitment to HTML5/WebKit, and so a threat to Apple), things go faster and faster :
Apple just stated through the iPhone OS4 license that non-natives applications (that is those using a compiler to transform code that do not rely on Apple’s SDK APIs into binary) will be excluded from AppStore :

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).

To remember Adobe did success recently going through Flash ban on iPhone, by using a compiler, that indeed will be provided as part of Flash CS5 in a few days…

Most of editors of non natives solutions (Unity, Corona, Appcelerator Titanium) don’t seem too much scared (they have the required skills to adapt to the new rules, or some tricks), as we can read at Corona’s blog (whose solution still produces a compliant XCode/Objective-C application through a compilation step – contrary to Adobe’s producing a binary).
For fake developers that were used to make fast porting without much implication nor care (this lack of Cocoa concepts use leaded to deceiving results, and typically to dispoasble/event targeted applications), the required changes will be more costly. However this cleanup will benefit the platform in the long run, and ensure better software quality !

Finally, as some say (see an interview of Backelite by Macgeneration), those that don’t want to make efforts to adapt to the target platform / Cocoa concepts (that is in the end very productive once the first step succeeded) may better go back to their less evolved langugages and non elegant solutions.

Apple’s strategy (that can now be deployed thanks to the amount of iPhone/Cocoa developers), alongwith the new idAd solution (based on HTML5), is a final no go for Flash on iPhone, notably Flash ads and associated revenues. Not only Adobe has to loose, Google also is threatened, as this market could generate billions of $ per year.

In reaction to this announce, a Google employee just (that is in a non official way) stated that HTML5 might not replace Flash in ads companies. However this is without considering the new framework that Apple is likely to unveil soon to create these contents (some ADLib derived one, with a web image and video editor, featuring a timeline ?) For other areas (RDA applications) there is still Cappuccino and Atlas.

Note : through AppleInsider we learn that another reason for the new SDK restriction could be related to iPhone OS4 multitasking compliance…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s