backtop


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 omnicronx on 4/9/2010 2:28:28 PM , Rating: 2
quote:
Since it's technically impossible for Apple to figure out that this particular Obj-C app was written by hand and that one was generated by some Obj-C code generator in Mono or something - there's no way to enforce this clause at all.
How do you figure? Are you telling me they won't be able to figure out code patterns in compiled code? COf course the fact you don't submit source to Apple will make it harder for them, but calling it 'technically impossible' is vastly incorrect. This could easily be an automated process by Apple if they so choose, not saying they will, but who knows, it still leaves the final decision up to them, if they feel the need to reject a certain app where they previously had no grounds.

If they take the time to figure out these patterns for the leading alternative SDK's, they can very much so figure out what tools you were using.


RE: No way to detect this
By Spivonious on 4/9/2010 2:48:02 PM , Rating: 2
But Apple never sees the source code, so they would have no idea what you used. It's all bits by the time it gets to them.


RE: No way to detect this
By omnicronx on 4/9/2010 4:10:25 PM , Rating: 2
Already explained why you don't need the source code.. Even compiled code will have specific code patterns that can be used to figure out how it was compiled. Generated code will follow certain patterns, have certain markets etc etc.. that will not exist in normal natively developed code.

Yes they will have to study these alternative SDK's to do this, but its not like its going to be a particularly hard thing to do.


RE: No way to detect this
By Pirks on 4/9/2010 3:26:09 PM , Rating: 2
quote:
If they take the time to figure out these patterns for the leading alternative SDK's, they can very much so figure out what tools you were using.
The SDK vendors will just obfuscate it.

I don't think Apple has any chance here since they can easily produce a lot of false positives and blame innocent devs that produce hand crafted code that just SEEMS LIKE the autogenerated code by .Net-to-ObjC translator or something.

This is eternal war between a cannon and an armor, and Apple has no chance to win it once and for good. If they figure out some pattern in say .Net SDK - the SDK vendor obfuscates/changes it and voila, Jobs sucks eggs again. This is Sisyphean effort, I won't be afraid of it at all if I were an iPhone dev using C# or AS or what not.

You can't technically enforce it, once and for all and without making any false positives.


RE: No way to detect this
By omnicronx on 4/9/2010 4:26:42 PM , Rating: 2
quote:
The SDK vendors will just obfuscate it.
Ha, easier said than done, and not fool proof either..

For example Novell could start changing these signatures, but then it would bone for everyone. Apple would just have to keep up with these new signatures similar to how Virus scanners do. Would there be a 100% success rate, no, could they figure it out the majority of the time should they choose, most likely.. i.e its a cat and mouse game, its not like ALT SDK's can just close the doors for good.

So unless you can get the source of the compiler itself (which is not possible for the majority of these ALT SDK's), and change it, you most likely can't just 'obfuscate it'.


RE: No way to detect this
By Pirks on 4/9/10, Rating: 0
RE: No way to detect this
By jezzza234 on 4/9/2010 10:20:53 PM , Rating: 2
To be honest, the fact that this is happening is going to deter developers from using technology that could potentially cause their software investment from not being allowed. I'm a .Net developer but I would rather invest in the time learning Objective-C than stand the risk of my app being denied after spending so much time working on it. The same will happen for many other people too


"This is about the Internet.  Everything on the Internet is encrypted. This is not a BlackBerry-only issue. If they can't deal with the Internet, they should shut it off." -- RIM co-CEO Michael Lazaridis














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