82 comments

[ 4.2 ms ] story [ 160 ms ] thread
This is epic, and I don't think everyone realizes what this means. Developers will be able to just... export. The revenue model for Flash games used to be: free + advertising. With this move, those same games can be released on the app store and actually charge money, or fall back to the advertising model. Its a simple way for developers to cash in. The funny thing, and this is what makes very little sense, is why did Adobe do this at all? There's no doubt that little feature cost them some serious cash, and for what? To make Apple rich?
I'm sure Adobe's motivation is to make money selling licenses to software developers. If I remember it is about $700/seat for this software. In terms of their cost, it would make sense that Apple did some of the heavy lifting on this as part of an agreement to keep Flash off their devices. Unity is another example of a company doing this same thing and making money at it too.
I'll second that. Adobe wants to become an alternative platform for the iPhone. Right now it's Objective-C or the highway.

I can't stand JavaScript (and therefore ActionScript) but, as an iPhone developer, watching this video made me think, "gosh, I should start learning flash". Objective-C is a nice language once you get used to it, but I can't imagine that it could compete against Flash in animation-heavy programming tasks.

No it isnt', there are plenty of languages you can program the iphone in. Straight off Apple supports C. Then a lot of people have added support for other languages.

All these have been advertised on here.

For the love of God, submit a link to the Apple resources on iPhone development in C. "Objective"-less, good ole C.
Haha yeah seriously. That's kind of a silly rebuttal :p
Not only that, but since those devs get their Flash apps distributed to portal sites, they can easily advertise the iPhone version inside their games. I'm quite sure a link to buy the app for your phone will be much more compelling than a random interstitial ad.
They had to come up with SOME reason for folks like me to upgrade from CS4 to CS5. CS4 is already so feature-rich I probably never would have upgraded.

Add this little gem, and well, here's my $400-$700. Done.

This is nothing but good. Let's see if Apple likes it. Didn't Apple dislike the iPhone apps made with .Net+Framework?
There are like 5-10 top apps built with Unity3D such as Zombieville USA that is Mono based and cross compiled. So in short, now they love them because they make money from them (30%).
Yeah this is good for everyone. However it might be bad for Flash's chances in MobileSafari, however. Apple wants to funnel people through apps, not web sites. If they can make the argument that the iPhone supports flash because you can compile to native format, it might take the heat off them w/r/t integrating Flash into Safari.
Seems like a huge opportunity for folks who are fluent in Flash/AS3 and haven't had time to jump on the Objective-C bandwagon. It's likely that since it's compiled down, it'll run faster than interpreted Flash! Great move by Adobe! (I'm curious if Flex will work.)
I would expect Flex to work as well since it's basically an actionscript GUI library written on top of Flash. There is a mxml compiler that takes your Flex gui code and converts it to a SWF. And it sounds like LLVM takes a SWF and turns it into Obj-c code so I think it would work.
I'm calling it now: ECMAScript will be the most important language over the next three years.
The problem is ActionScript is pretty far from the EMCAScript you get in browsers - ActionScript was based on a proposed standard for ECMAScript which was later abandoned, so it's pretty much a different language now.
Fair enough. Probably true for AS3, which seems to superficially resemble Java. One of my hobby projects (HipHopGoblin) uses a bunch of AS2, which I find very similar to JavaScript.
AS3 is quite similar to Javascript also -- you can't do as much with the prototypes, but it still has closures, allowing a functional style; and everything's essentially an Object with properties, allowing a dynamic style. You can turn off strict mode and it won't do compile-time type checking, or you can type specific signatures as "*" and they will not be type-checked. This means you can do all the duck-typing you like, instead of defining a Java-like interface.

One of AS3's goals was definitely to become more like Java, for whatever reason, but almost all of the new Java-y-ness is optional.

This is true regardless of this latest development.
Adobe is using LLVM.

There is no runtime.

+1

http://www.adobe.com/devnet/logged_in/abansod_iphone.html

That's some amazing work. Adobe must have dedicated the A-Team to that task.
Never understimate Adobe. Despite their misguided stabs towards DRM (oh god when will they learn) they have some good engineering there.

PDF, Photoshop, Flash, despite all their flaws and sometimes dubious origins, wouldn't have dominated their respective markets for decades if there wasn't also at least a bit of quality engineering in each. ;-)

I don't know why parent is being modded down. Adobe has some fucking mind-blowing engineers, especially on their core teams. Advanced technology labs is putting out parc-quality work in the field of graphics.
(comment deleted)
"There is no runtime"

Ah, so they got Flash on the phone by taking away the bit that makes it suck bells. Good job, Adobe. Amazing what you can do when Apple forces you to not to be craptacular.

Thank goodness they aren't as bad a case as AT&T. I'm still waiting for some Apple-y goodness to rub off on them.
Does that mean you'd like Flash content to run as non-VM-boxed binaries on your PC? Or did I misunderstand what you meant?
It just means that I loathe the Flash runtime on the Mac: it's slow, kills the CPU and as a result sends the fans spinning. This is one reason (beside the business ones) why it was never going to get on the iPhone.
Right -- and next you're going to tell us that each and every website that uses flash - you're going to install an application for on your mac.
Lol. And, LLVM is mainly sponsored by Apple. Pwnd.
We created a new compiler front end that allowed LLVM to understand ActionScript 3 and used its existing ARM back end to output native ARM assembly code. We call this Ahead of Time (AOT) compilation—in contrast to the way Adobe Flash Player and Adobe AIR function on the desktop using Just in Time (JIT) compilation.

"AOT Compilation"?! Amazing!! They should patent this!

but yeah, sounds pretty cool.

The MacRuby guys are doing this as well. (AOT) They are also using LLVM incidentally.

What I'm wondering about is how they do AOT for dynamic code. Do they have every possible path for a data type compiled? This would seem silly..maybe LLVM has some clever ways about this?

No. Your message sends all end up going to the same place where you pass in (a) the target of the send (b) and the message you were sending. This handles dispatch to wherever that's supposed to end up. Objective-C itself handles it this way using objc_msgSend.

In fact... since MacRuby is built entirely on top of Cocoa primitives, it wouldn't surprise me if they've translated all Ruby messages into Objective-C messages and just use objc_msgSend for all of this sort of dispatch.

For an interesting exploration of this particular call, check out this blog post: http://ridiculousfish.com/blog/archives/2005/08/01/objc_msgs...

so couldn't you then take this and then target AS3 to say native x86 code, bypassing the Flash VM entirely?
This is essentially what AVM2 does already, only it's JIT rather than AOT.
That explains how they deal with your code, but what are they doing for the Flash Player bits? All of that wasn't written in ActionScript, right?

For example, if your app needs to play a video, where is the video player coming from? If it's Adobe's own, doesn't that mean Flash-equivalent bits are going to be in every compiled app? In that case, and this would be consistent with what they're saying, the main reason for this AOT compilation instead of JIT is apparently to comply with Apple's legal terms.

Looking at some of the apps Adobe are showcasing - it appears they're all around 10mb, which suggests they're including all the runtime bits in there.
They're probably using a similar strategy to Alchemy: map AS3 library calls to a Flash framework implemented in the target language. (In Alchemy's case Scott Petersen implemented a C VM in AS3, linked with the C std lib.) Most likely the entire framework is being bundled with every release, without regard to dependency.
Thanks robc and ed. In that case, I don't think this is as impressive from a technical perspective as some people thought. Again, this AOT compiler is not what made Flash apps technically possible on the iPhone; Adobe could've used this same bundling technique with the JIT compiler. It looks like they've done this just to satisfy Apple's terms.
Looks like it'll have all the AIR bits-and-pieces in it. So you'll get database/filesystem access, etc.
MonoTouch (monotouch.net) is exactly the same approach for .NET instead of Flash.
In short: no Mac required for developing iPhone apps. flash games which are extremely easy/quick to develop can be ported into iphone apps.

Conclusion: iPhone app development prices will go down the drain for most of the apps. There will be millions of apps on the appstore. Prices of apps will go down further.

WOW!!!

.99 is the minimum you can go, so iphone apps wont get cheaper. Flash games tend to run really slow even with beafy core 2 duos, so I'm wondering if the performance will translate for smartphones.
I guess you didn't watch the video? The apps appeared quite snazzy, I am sure they used open gl es for them, so there is no reason they should be.

I hate flash, but I hate dealing with open gl even more. Maybe I will have to look into this.

While development costs may drop, it's hard for most app prices to drop any further as Apple has set the price floor at $0.99 cents.
Free + email harvesting/advertising/spam?
Perhaps, but I think this is too cynical. You forget about the cost of Flash (assuming you're being legit), the cost of being able to put up stuff on the App Store, how potentially difficult it is to adapt the application to the iPhone, and how annoyingly stringy Apple is about bugs. This will surly shoo away a large amount of amateur Flash-ists.

Plus, you're forgetting that the market is already diluted. The only apps that make it are those which get advertised heavily or a big blog discovers and writes about it. Therefore, these "million of apps" will hardly make a difference in how difficult it is to make significant money developing iPhone apps.

The App Store is not going to become Newgrounds, I promise.

In short: no Mac required for developing iPhone apps. flash games which are extremely easy/quick to develop can be ported into iphone apps.

Remains to be seen. You still have to sign applications to submit them to the app store. Adobe hasn't made it clear if they reverse engineered this bit yet, or if it simply calls the codesign binary. If its the latter, you still need a Mac.

I'm not sure I really get this sort of comment. Is a mac really such a hurdle relative time, effort or monetary cost?
You can find an Intel Mac Mini for ~300 on eBay. Its not terribly expensive or hard to get set up.

All I'm saying is that you may still need a Mac if you intend to put your app on the app store (or on your own device if you don't jailbreak). You need a Mac because Apple hasn't released the code for the codesign application; only a binary that runs on OS X only.

The codesign application is - you guessed it - responsible for signing an application's binary to run within the iPhone's sandbox. This usually done automatically by Xcode when you build for the device (for debug or distribution).

Adobe hasn't made it clear how they handle this step yet. They may have reverse engineered codesign itself - so you can develop on Windows. Or they may have just looked at what Xcode does when signing with codesign and duplicated that - in which case, you still need a Mac for at least your final step (submitting to the app store) and should really have a Mac before that step (to test your app on a real device). Especially since you can't use the iPhone Simulator if you use this for your iPhone app.

(comment deleted)
I didn't imply that you don't need a mac. I'm just puzzled by people who seem to think that this is so important or that mac ownership is a substantial hurdle to iPhone app development.

As you say, the minimum requirement is not all that high. A mac is an additional machine usually $1K-$2k, something that developers need to spend money on from time to time. If you really don't want/need one and only use it to develop one small app, 500 for a mini (or 300 for a used one) is not terrible.

I'm just puzzled by people who seem to think that this is so important or that mac ownership is a substantial hurdle to iPhone app development.

Because it is a substantial hurdle. The hurdle comes down to: Do you want to be able to test your app while developing it? Or do you just want to write it, make sure it compiles, and ship it?

If you just want the latter, then you will be able to get away with not owning a Mac to do a lot of testing and to sign with. You won't likely end up with a very good app. But you will have an app. OTOH, if you want to make a very nice application, that performs well, has a good UI and so on etc, you really should have a Mac. It gives you two big things: The iPhone Simulator and the ability to put apps on your device.

While the simulator might not matching device behavior for optimizations (if you need to do any), is fantastic for laying views out and testing if logic works. Its great for fixing small bugs that would exist also exist on the device. There is a caveat: not all behavior on the Simulator is the same as the device. This is frustrating at times. But, with a Mac, you can actually put your app on an iPhone. Codesign is (AFAIK), very much Mac-only.

Yes, you can develop on Windows or Linux, jailbreak and put your app on your device that way, but, you really do want to test your app in the same environment that a majority of your customers from the App Store are going to have. This means a non-jailbroken device. Which, again, brings us back to needing to Codesign. And needing a Mac.

You've got me backwards. I agree with you. I understand why you need a mac. I don't understand why it is such a big deal to have to buy a one. Just buy one. If you are doing this for a living, this seems like a reasonable expense. If you are doing this semi-pro, well then get your hands on a used machine cheaply.

If you are neither, Apple's not really catering to you. That's true. Jailbreak or do something improvised. Even someone doing it for non monetary reasons.

By hurdle I meant buying one.

By puzzle I meant people hearing about something like this and thinking "now I can develop without a mac" rather then "now I can develop in flash."

Why would they have needed to reverse engineer anything? I don't see how they could have done this /without/ Apple's permission and help.
Why couldn't Adobe do this on their own? They have the money to throw at smart engineers if they feel the need to.

And its not exactly like a lot of what they needed was completely undocumented; ARM and Mach-o binary formats, how to link against frameworks, etc. I'm not pretending that I would be able to do something like this on my own, but, its definitely possible for a group of smart people who have the right background to do.

Yes it is a big hurdle for me.

I own a Dell laptop running Ubuntu and a desktop I've built myself running both Ubuntu and Windows.

Because I live in Europe, the cheapest MacBook Pro is 2233 USD. And the cheapest Mac Mini is 1000 USD.

A Mac Mini doesn't cut it for me because I travel a lot (not long distances, but enough to keep me from having a stable office). I won't consider the simpler MacBook because I had one that I've taken to the repair shop 4 times in one year. The MacBook is simply not made for high-workloads.

And MacBook Pro is just expensive. I've payed 800 USD for my Dell Inspiron and it's been running for two years with no problems. The MacBook Pro is just overpriced. I don't care that they are bundling the latest Intel processor in it. I don't want the latest hardware available. I'm happy with just 2 GB of RAM and a big-enough hard-disk. A colleague of mine had a MacBook Pro and the motherboard fried when he spilled some coffee on the keyboard. I've spilled coffee (with lots of sugar) on mine and besides the keyboard getting sticky, nothing happened.

Besides, I always hated Windows because it is too locked down. I also stay away from proprietary technologies because the skills aren't transferable. But having to go all-Apple to develop for the iPhone is just ludicrous.

Nope, you can actually develop using just Windows. From Adobe's Ryan Stewart tweets: http://twitter.com/ryanstewart/statuses/4636390111 "One of the biggest things about the Flash/iPhone news is that you no longer need a Mac to build iPhone apps."

http://twitter.com/bit101/status/4636544212 "@ryanstewart really? so it uses your cert and provision and creates the .app file? no xcode needed?"

http://twitter.com/ryanstewart/statuses/4636642995 "@bit101 Yup, no Xcode needed."

Flash Professional CS isn't exactly cheap.
iPhone apps probably won't go down that much. You'll still have to pay at least $0.99 for those apps you'd get on the internet for free, and this is because you're getting the app on a closed, mobile platform that runs in the palm of your hands. Then there's the $99 fee to get it into the app store, which is part of the closed platform problem.
Will it work as well as Flash now works on OS X? If so, then thanks, but no thanks.
Well, you could watch the video. Seems to work pretty well.

I hate flash, but compiled flash might just be ok.

Wow, so owning a Mac will no longer be a requirement for iPhone development, as Flash Professional supports Windows also. Even MonoTouch requires an Intel Mac.
This would be pretty great - but I'm not sure what Adobe has planned for signing the app (and if they can take any of the pain out of that process it would really make life a lot easier).
So a few questions in my mind - what does this do to wait times for getting apps into the store? How much stricter is Apple going to be on non-conforming UI? I really think Apple will impose artificial controls on the market to prevent it from bottoming out and flooding their top tier producers - or perhaps finally make a AAA section for the store.
Do you think Apple would take issue with making Flash controls look identical to their own?
IIRC there was an issue about an Aqua PLAF for Swing years ago.
Did no one else anticipate this? Lots of other people have been doing this for awhile (mono foundation, unity, gambit scheme, etc.). Is this a game changer? Yes. It opens up the door to tons of developers. Will applications written in actionscript still have the same shortcomings as the other aforementioned languages? Probably. Looking at the AS apps in the store right now they all have larger than expected file sizes. Additionally I don't see any of them taking advantage of any of the latest API features rolled out in iPhoneOS v3. Each time Apple releases a new iPhone OS version (with all of the API changes/additions) all of these tools need to be updated and re-released. Moral of the story? If you want to take advantage of the latest API features and remain on the cutting edge of iPhone development it's best to stick with objective-c.
Before everyone gets too excited over this, admittedly very cool technical achievement, how will this affect the look and feel of apps making use of it? Games always tend to use completely custom UIs, so this will be a neat tool at the disposal of game devs. But how will business apps feel? Will text boxes be CocoaTouch-based or some Adobe-proprietary text box?

These things tend to matter in achieving a consistent look and feel to users. I've never preferred Java apps on either Windows or Mac OS X to native ones, primarily because they are only ever 95% of the way there in providing consistent look and feel. There's always something that is just off ever so slightly.

Even if CS5 won't include it at launch, I'm sure it's only a matter of time before there will be a full-fledged library of "iPhone-like" controls available.

Besides, Apple can be as anal as they want about interface consistency before they approve something to the App Store, and they're probably not thrilled by this. They can use the interface excuse to great effect if they choose, to neutralize the effectiveness of this tool by simply rejecting many Flash apps.

It will be interesting to see how Microsoft reacts to this. I am in the early stages of planning an application that might have a rich client component. Since the rest of the stack is .NET, it made a lot of sense to look at Silverlight, but now that I could potentially deploy the same code to an iPhone (and probably other mobile platforms as well) with minimal extra effort, it's hard to recommend Silverlight.
Unity uses a .NET runtime for it's code, you might be able to port it over.
So after all of my investment and time learning the Cocoa Touch platform these flash guys come in with 10+ years of crappy code and inundate the app store without even having to reference count their objects. There goes my consulting business :(

If it's been hard getting noticed in the app store imagine what it's going to be like when every flash app in the world is ported over.

This makes us at Stormpulse really happy, since our map is written in ActionScript, and people have been screaming for an iPhone app.
I sure hope IndestructoTank is ported right away. One of my favorite games and I think it us well suited to iPhone gaming.
The FAQ is pretty informative: http://labs.adobe.com/wiki/index.php/Applications_for_iPhone...

I especially found this useful:

<quote>Which native iPhone APIs and functionality are supported when using Flash tooling?

The following native device APIs and functionality are supported:

- MultiTouch

- Screen Orientation

- Saving images to Photo Library

- Accelerometer

- Geo-location

- Cut / Copy / Paste

Can applications take advantage of hardware acceleration?

Yes. In some cases, the rendering of Flash content will be hardware accelerated.

We will publish more information on this when we release the public beta.</unquote>

I doubt if people can build apps on windows "yet" until there is official blessings from Apple itself

application signing and testing on iphone simulator, phone provisioning and developer profile for iphone, debugging, profiling all need a mac, xcode and friends

the machine shown on the video was a mac

I think the biggest thing people are missing here is one of the best advantages: Demos!

Currently Apple doesn't give a way to distribute demo copies of software. But if your app is already a Flash project, you can export that to the web in a trial form for people to play and test out. We've had videos and screenshots, but this is a much more effective way of selling.

Check out an example: http://www.muchosmedia.com/justletters/ All you've got to do to build a demo is export to SWF instead of IPA. Easy cheezy.

This is a significant development and seems to be win-win for both Adobe and Apple. It will be very interesting to see how this plays out and if iPhone App development in Windows/Flash is as seamless as Adobe is claiming. But if it is, along with the support for RTMP, Remote Shared Objects, AMF, and SQLLite, it could be a big boost for Adobe.