Print 39 comment(s) - last by AntDX316.. on Apr 12 at 1:23 PM

Apple may be bringing video chat with the next generation iPhone.  (Source: Tuaw)

Apple CEO Steve Jobs has taken another swipe at Adobe's Flash restrict apps developed in a Flash environment. The move comes at the expense of app developers.  (Source: AFP)
Developers can no longer use non-C language development platforms

Apple fans received a bit of good news, when observers studying the newly aired iPhone OS 4.0 SDK used the utility iStat to reveal a new Apple app called "iChatAgent".  Most observers say that it's unlikely that Apple would just release another instant messaging app; most believe the app will be a video chat app, and that the upcoming fourth generation iPhone will have a front-facing camera to support it.  An Apple patent hints at this development.

Developers, on the other hand received some bad news from Apple.  The new SDK license agreement states:
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).

What does this mean?  What might seem like an innocuous addition is actually another swipe at Adobe by Apple.  Adobe last October released an iPhone-ready Flash CS5 development environment that took apps written in Flash and then converted them to an iPhone-ready binaries using linked Apple APIs.

Apple has been rallying to promote a proprietary video codec-based version of HTML5 to combat Adobe's proprietary Flash format, which Apple CEO Steve Jobs accuses of "crashing Mac computers" due to it being, in his opinion, buggy and insecure.  The good news is that HTML5 is an open standard and could support other video codecs.  The bad news for open software advocates is that Apple is pushing for the web to exclusively use a proprietary video codec with the new HTML version.

For developers the battle is bad news as well.  On top of restrictions on programs that execute their own code, apps the overlap the iPhone software's functionality, and certain adult-themed apps, developers now will have a much harder time porting their Flash apps to the popular platform.

For small developers, it might be less of a deal.  Its unclear if Apple could detect the subtle differences in compiled code between a binary made with the Flash development environment versus a C development environment.  Small devs might be able to ignore the restriction, at their own risk, and get away with it.

For big developers, though, like Condé Nast, who were banking on using the Flash development environment to port their Adobe Air apps to the iPad and iPhone, they are now forced to scrap those efforts and resort to a full port if they want to get approved.  That may tempt some to switch over to Google's Android, which has a soaring number of apps and much fewer developer restrictions.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: No way to detect this
By Pirks on 4/9/2010 6:08:01 PM , Rating: 0
Okay, but what if some SDK vendor produces a source code converter that's capable of producing the ObjC code that looks like it's been written manually, without some special SDK-only calls and constructs and stuff, you think that's technically impossible to do?

Okay, here's a concrete example for you. Let's suppose a .Net SDK vendor decided to make an SDK for cross platform .Net dev on iPhone and other phones. It started from scratch and created a .Net class lib that precisely mirrors ObjC API calls, all them existing on the iPhone.

Then in order to get iPhone apps ported to other platforms it only has to emulate this functionality by some thunks or emulation subroutines on other platforms. Usual stuff and noone from another platform doesn't care about those emulation layers since they don't prohibit alternative frameworks the way Apple does now.


The end result of it will be the ObjC code that's autogenerated from C# and... looks exactly like a manually written code since it has no special calls or emulation routines, it looks as if someone just wrote some random ObjC code doing some stuff and calling some standard native Apple API.

See what I mean? This code, that has absolutely no emulation features (because SDK library was designed this way! To emulate/mirror Apple API) is technically impossible to distinguish from the manually written code.

If you don't think it is, tell me what can be used as the pattern to search for. No emulation calls. Only standard API calls. Just some random ObjC code.

So, what to look for in this case? What can potentially give out the nature of the code to Apple investigators?

Question number 2, even more tricky one, I don't think you'll answer: what if .Net SDK vendor even STARTS WITH DOTNETIFYING Objective C? Say they write a CLI compatible bytecode generator for ObjC, then add .Net class lib that mirrors Apple native API.

Bingo. Now this is somethig that noone can distinguish from the manually written ObjC app, you know why? Because IT IS a manually written ObjC app... using native Apple APIs... but... you click a button and voila - the whole project is exported to .Net and what not. ObjC is compiled to CIL bytecode and all the native Apple APIs are emulated in a class library.

So the bottom line here is: if you emulate Apple language and classes on other platforms - there's nothing Apple can do about it. There's no way to distinguish apps written using this SDK from apps written with Apple SDK.

So as you can see it's technically possible to do cross-platform dev on iPhone using alternative SDKs, but you know those SDKs just have to adapt to whatever restrictions Apple thinks up.

"I f***ing cannot play Halo 2 multiplayer. I cannot do it." -- Bungie Technical Lead Chris Butcher

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki