

Apple's attempt to block Flash on the iPhone/iPad? - probablycorey

The new iPhone Developer Program License Agreement states...<p>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).
======
pg
It sounds like they are trying to prevent people from writing apps that are
portable to other smartphones, since the obvious way to do that would be to
make an intermediary layer.

Or am I misreading this? Any iPhone experts have opinions about what this
means?

~~~
volida
I am not aware of the inner workings of how the Flash Packager for iPhone
works (<http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/>) but
probably they are not translating your code from ActionScript to native C/C++
before compiling it, so probably this would affect it.

~~~
Zev
My understanding of what Adobe was doing is that they're using LLVM to output
the necessary ARM binary directly, not going to C/Objective-C and then using
the standard tools by Apple to make the binary. It is probably worth noting
that Apple doesn't even use LLVM/Clang for the iPhone yet; you still have to
use gcc-4.2 to build your app.

What I'm curious about is what Adobe is that makes binaries much larger than
the size it would be if it was in ObjC. As an example, the binary for Trading
Stuff (only picked on because it is free) is 14.1MB. Thats rather ridiculous;
I don't think I've ever come across an app written in ObjC for the iPhone that
was 1.4MB.

And looking at the reviews for Trading Stuff, it doesn't seem like the app
performs very well. Of course, that could be due it being written poorly. But,
my initial inclination is to think otherwise.

~~~
wmf
Apparently Flash apps are statically linked to a massive Flash runtime library
whether the app needs all of it or not.

------
rit
Interesting.

MonoTouch, which is the Novell/Mono team's rather fantastic port of C#/.Net to
iPhone, compiles down to native code and apparently that was OK with apple to
begin with. Unity3D which is a popular 3d framework for many platforms
including iPhone (Where it runs a lot of games) was available before MonoTouch
and is Mono based.

Assuming the OP is correct in the "new developer license agreement" statement
(e.g. the relevant section is entirely new or changed) the "Originally written
in Objective-C, C, C++ or JavaScript" is worrisome. It technically invalidates
MonoTouch. Even if MonoTouch is hard translating code to One of the blessed
languages before compile, you didn't write it ORIGINALLY in it.

And love or hate Mono, .Net, C#, etc etc. the fact is that it brings iPhone
development to a larger audience which is (IMHO) overall good for the iPhone
app world.

I seem to recall Adobe was demoing a similar system a few months back - which
would compile down a Flash app to native code in more or less the same way as
MonoTouch does. I guess it's entirely possible that Apple is targeting this in
their change, but unlikely as this wouldn't allow you to run downloaded flash.
It would simply let you download Apps from the store which were written for
Flash, but since they'd been translated to native runtime probably wouldn't be
the battery hogs that apple seems to fear.

I've been watching Apple long enough to think this may not be a case where
they're targeting a specific person/company, rather ... it's future leverage.
If they run up against something they don't like (there are obviously lots of
things like MonoTouch and more coming along) sometime in the future they now
have a clear one liner to point at for "VERBOTEN". They may still however work
happily with companies like Novell to produce a grey-area inhabiting
MonoTouch.

UPDATE: For the record, the MonoTouch FAQ (<http://monotouch.net/FAQ>) states
very clearly "MonoTouch is delivered as a static compiler that turns .NET
executables and libraries into native applications. There is no JIT or
interpreter shipped with your application, only native code. ". Obviously this
distinction used to pass the test.

~~~
ryanhuff
I don't see how Monotouch is not at risk here. While they may not use an
interpreter, there is no objective c source code used in the building of a
Monotouch application.

~~~
Matthew_Fabb
Well, that could be a problem since Apple's new agreement says "Applications
must be originally written in Objective-C, C, C++, or JavaScript as executed
by the iPhone OS WebKit engine". So if the code is written anything but those
4 languages, then the resulting app is breaking Apple's new licensing
agreement.

------
theBobMcCormick
WTF?? I'd like to see the Apple fanboys defend this as anything other than
Apple being dicks. I can think of no legitimate way in which this "preserves
the user experience" or "keeps users from getting confused" or any of the
other usual Apple apologies.

------
barrkel
This is pretty bad. No more MonoTouch, nor any language innovation in software
tools targeting iPhone etc. permitted.

To be frank, as an employee of a tools vendor which sells an IDE (Delphi)
whose language is not one of Objective C, C or C++, this is pretty scummy - a
low blow.

(I speak for myself, not for the company. of course.)

------
dannyr
I view this also as Apple forcing developers to make a choice between Android
and IPhone.

Let's say you have limited developer resources and can only develop an app for
one platform, most would choose the IPhone due to its large install base.

------
blasdel
They really should have just let Flash CS5 apps fail in the marketplace, or
just been very selective about quality when approving them.

~~~
skeletonjelly
You'd think their already very selective process would have taken care of it
then.

~~~
Matthew_Fabb
According to Adobe, there's already over 100 iPhone apps in the iTunes store
made with the private beta of Flash CS5. So Apple currently isn't being
selective enough. It seems without Adobe advertising which apps are made with
Flash CS5, that users aren't noticing the difference between them and apps
made with Objective-C.

Here's a developer who just got his iPhone app made with Flash CS5 approved
just this afternoon: <http://twitter.com/james_eberhardt/status/11850738164>

~~~
gte910h
It's not going to be a problem until the new agreement comes into effect
(which I've read that you have to agree to by the 22nd).

------
doki_pen
It seems insane to me that companies spend tons of money creating apps only to
have the rug pulled out from under them. Is there any legal action that could
be taken for Apple changes the rules like this? Is there at least a grace
period? Can people continue to use the older version of the API?

~~~
sstrudeau
I'm sure if Adobe's lawyers can find any hook for a lawsuit, they'll be all
over it.

------
gte910h
I'm sorta surprised they didn't wait until Tuesday (after CS5 drops) to drop
this bomb after everyone bought flash CS5. But then again, that's likely why
they did this show and tell today, to make sure people didn't buy flash.

~~~
joeminkie
I'm pretty sure they're not releasing CS5 next week, just previewing it.

~~~
gte910h
Nope, it's the launch: <http://cs5launch.adobe.com/>

~~~
chrisbolt
CS5 isn't shipping for another month, they're just unveiling it now.

[http://www.appleinsider.com/articles/10/03/23/adobe_to_offic...](http://www.appleinsider.com/articles/10/03/23/adobe_to_officially_unveil_creative_suite_5_for_mac_april_12.html)

~~~
gte910h
And they call that a launch? What a horrible abuse of the English language.

------
mkramlich
Number one I think it's a pretty obvious smack at Adobe, countering their
planned CS5 which was supposedly to allow you to use Flash tools to compile to
an iPhone app. I don't believe there is any legitimate move for this, it's
purely business, anti-competitive, "Not Being Nice".

Number two -- and I think this was more of a bonus not the main purpose -- is
a blow against cross-platform toolkits.

------
albertzeyer
Whatever layer (Mono, Java, ...) you may want to add, just let it generate C
code instead of native code. Problem solved.

~~~
wmf
No, if your app is _originally written_ in C# or Java and compiled to C you
lose. At best you could try to play hide-and-seek so that binary analysis
won't reveal any hint of the source language.

~~~
jcdreads
My apps are always originally written with pencil on paper, then in pseudocode
that gradually transforms into something that runs. Even those with nothing
but ObjC sources. This new requirement seems, if not unenforceably arbitrary,
then at least incredibly hostile to developers. Alas.

------
tvon
I'm a bit confused, what is C++ doing in there? I thought the XCode path was
all Obj-C for iPhone apps...?

~~~
gte910h
The iPhone's native API is a mix of C and ObjC. Some libraries are written in
C++ but have C bindings for the most part.

All of these languages can relatively easily call one another (even on the
iPhone). As C++ is a huge deal in the game world, lots of shops just went
pretty much straight C++.

XCode is just using clang to analyze/gcc to compile then signing it with Apple
signing programs.

If I'm not mistaken, the entire app toolchain was inspired by the "open
toolchain" created by the original jailbreakers before there was a native app
api.

------
donohoe
I believe this means PhoneGap is still okay?

~~~
bad_user
No it's not because it is using an intermediate layer to connect Javascript
with APIs it doesn't normally have access to.

Apple is practically killing all tools that would make cross-platform
development bearable.

~~~
Zev
I haven't used PhoneGap, but I thought that it was just a UIWebView and
Objective C? In which case, it would still be allowed.

------
albertzeyer
Btw., what does this mean for SDL?

------
hockeybias
As Dave Winer might say, "They're throwing us (a bit deeper) into the trunk".

~~~
Estragon
Climb out now. Android's only going to get bigger. Stuff like this is only
going to accelerate its growth.

------
TomOfTTB
I don’t see the issue here. Pretty much every company has taken to protecting
themselves against everything under the sun in their license agreements.
That’s (sadly) standard practice at this point.

Beyond that there’s a legitimate need for this particular clause and that’s to
prevent vendors who would market poorly written tools that create buggy
applications.

So the question isn’t “does Apple have the clause” it’s “will Apple use the
clause against legitimate developer tools like Adobe Flash or monotouch”.
Until they do I don’t see a need for criticism.

~~~
jonknee
If the apps are junk Apple could simply not approve them. There is no need to
make a special case for apps written in other languages, it's quite easy to
make a buggy app in C/C++/Objective-C.

~~~
TomOfTTB
Sure there is. If a cheap framework is produced and it's allowing thousands of
junk apps to be turned out by spammers or whoever it in Apple's best interest
to reserve the right to ban the framework itself. Rather than dedicate a
fairly highly paid technical person to reviewing each junk app.

~~~
confuzatron
Do you mean cheap as in "not made by Apple", cheap as in "I cant think of a
meaningful adjective but I want something negative" or cheap as in "costs
nothing, same as the tool used to code Obj-C"? And let's hope these mysterious
spammers don't learn how to use Obj-C. And you need to pay money to have the
right to submit apps, right? They can pay the highly paid technical whatever
out of that.

