Apple's attempt to block Flash on the iPhone/iPad? | Hacker News Reader

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

46 pointsprobablycorey57 comments

The new iPhone Developer Program License Agreement states...

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

View on HN

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?

It definitely sounds like they're trying to kill MonoTouch (C# iPhone development) and other development environments like it.

I really don't see the point of this. It just means less applications and less revenue for Apple.

Actually, it probably means more platform specific code and more headaches for the developer.

Meaning, I doubt Apple will suffer much from developers declining to code for it.

[This was all out of date information, so I removed it so as not to cause confusion.]

UPDATE:

Actually, the guys in the office just informed me that everything that used to be true is not anymore. Sorry, everything I wrote is probably wrong as of this morning it seems. Wow. Even more reason to just use Objective-C.

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.

Even if they did the app still wouldn't be "originally" written in one of the approved languages.

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.

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

example in the studio

I'm a developer for android and iPhone. What this is is a blatant attempt to stop people from coding once and publishing on both Android and iPhone. Currently you have to code 1x for each phone.

I'm not going to pretend to be an expert, but, my thoughts on this are that this is just another (poorly made) attempt by Apple to keep what they perceive to be inadequate applications off of their App Store. Any side effects[1] of their decision are simply added bonuses, not part of the primary reason behind it.

[1] With the most obvious side effects being not allowing a "code once, use anywhere" environment to gain popularity and being a direct shot at Adobe (CS5's release is only a few days away).

I agree it's a blow against Android/Java and Flash/ActionScript, but also (probably and to a lesser extent) C#/.NET, and any other cool, modern, high-productivity language like Python, Ruby, etc.

I've shipped about 9 iPhone titles over the last 2 years, and my 2 biggest gripes had become #1 the App Store submission process -- which they finally improved significantly a few months ago -- and #2 that I was forced to produce and master so much iPhone-specific code & rituals. Rather than more reuseable/leverageable technology like HTML, Python, Java, Unix tools, etc. In other words, I was becoming a share-cropper.

So they seem to have improved #1, but now much worsened #2.

Makes me more glad I've stepped away from it recently, despite my love for the device as an enduser.

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.

MonoTouch is a commercial product ... and they (Novell) were probably hoping for a business plan to finance their open-source development.

Unity is very successful in the iTunes store, with at least 1 game in the top 10 developed with it.

Adobe CS5 would be great because of their authoring tool, and no matter what your views on Flash are ... that's what the approval process is advertised for ... to remove crap from the app store, and I'm pretty sure you can write optimal apps on top of Flash.

What the fuck are they thinking? If this is not a mistake, couldn't they announce this sooner, before all these companies waisted time on developing their products?

This is just proof that having your business relying on a company that thrives from locked-in, proprietary platforms is a really stupid idea that should be taken with caution.

And again, how can I recommend an iPad to my mother or other less technically-inclined people? What stops them from locking those users out of their own device they paid for, if such a thing becomes aligned with the interests of Apple?

The rule seems to restrict more than can be verified in reality. Since you don't submit the source code, there's no way to tell what language you used. As long as it doesn't do dynamic code generation, everything should work.

(of course if you don't mess with the binary after compilation, the language could be identified in many ways, but you can as well change the result to look like whatever you want)

Ex Reverse engineer (and current iPhone Developer)

Nope, you can tell. Especially if you have the tool itself on your desk when you try to develop a test (as Apple will surely be buyers of). If it doesn't look like Objective C, C++ or C in its call parameters, flow, etc, they'll "know" well enough to hold you up in their queue process until you "send screenshots of the source"

The boilerplate code technique (where C code is generated) can even be detected (although has more false positives).

The Adobe sourced Flash binaries are supposedly trivial to tell, and I'd expect MonoTouch etc to also have that issue.

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.

I'm not saying it's not at risk. I'm saying it MAY NOT be specifically targetted. This may be a shotgun clause that Apple pulls out as needed, rather than a "Hey Novell/Adobe/Unity cut that shit out as of now".

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.

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.

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

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.

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

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

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

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

The very selective process that allowed the Fart app, but rejected the Google Voice app? That one? :)

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?

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

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.

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

Nope, it's the launch: http://cs5launch.adobe.com/

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

http://www.appleinsider.com/articles/10/03/23/adobe_to_offic...

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

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.

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

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.

"Originally written" is not really well defined anyway. Nor can be determined when you got pure C code at the last step.

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.

Honestly, I could see a judge striking down that clause due to the lack of definition on "originally". This seemingly prevents ports to the iPhone of stuff originally developed on other platforms in say, Java.

I agree that seems to be the solution. It does push some of these vendors (Adobe) back months though, which may be their strategy.

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

some low level libraries and frameworks are written in C and C++, which can co-exist with Objective C in the same project. For example, the Chipmunk physics engine is in C, and the Sound Engine multi-threaded sound library is in C++

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.

I believe this means PhoneGap is still okay?

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.

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.

Btw., what does this mean for SDL?

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

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

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.

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.

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.

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.

MonoTouch, CS5 and Unity are commercial tools that, you know, cost money and are not cheap.

Why would a developer or a company invest money and time in those tools, only to give the iTunes approval process yet another reason for rejecting his app?

It kills these businesses, even if Apple might decide to look the other way in the approval process.

I was also starting to wonder when I'm going to see apologetic views on this, as is customary for anything Apple does :)

I don't buy this. First, the precedent will be set fairly quickly. If Apple does start banning all Unity or MonoTouch apps I GUARANTEE we'll hear about it days after it starts to happen (as we have with every other app). So unless Apple is actually going to kill of these frameworks it's not an issue.

Second, if you're a hobbyist you aren't going to buy a $2,000 framework and if you're a business $2,000 isn't that much for a software lic. I don't see the cost being prohibitive here unless, as I said above, Apple makes it clear they will ban these frameworks (at which point it's all moot anyway)

Unity has a free version and you can first develop with it, then buy a license. Productivity is more valuable than the license price, and Unity is a productive framework.

The price for MonoTouch is something like $399 for a single developer ... which is really not that much considering that you already paid for over-priced hardware.

All of them provide an easier path to developing for the iPhone when you're not used to ObjC / Cocoa and all of them enable shared business logic if you want to go multi-platform.

Apple already makes it clear they want to ban these framework. It's like a bank that has the right to take your house (according to the contract you agreed to) but it may take some time before it does it ... if it's in the contract and you don't do anything about it, then it's only a question of time. That's how things work ;)

Reply on news.ycombinator.com