

Adobe Updates Flash Builder and Flex to Support Building iOS Applications - whiskers
http://blogs.adobe.com/flashplatform/2011/06/build-mobile-apps-for-android-devices-blackberry-playbook-iphone-and-ipad-today.html

======
cmchien
I don't know the specific tech that Adobe is using, but I'd look pretty
carefully at the technology before committing to a platform like this as a
true cross-platform development environment. "Cross-platform" can mean lots of
different things.

We had a native app developed in Android. When we decided to create an iOS
version, we selected Appcelerator after reviewing a few different options and
seeing what we perceived to be good adoption of Appcelerator (and after
talking to another firm that chose the same thing). And, we (mistakenly)
thought that it's "generating native code", so, if anything goes wrong, we can
always debug in the Objective-C. Right?

Wrong.

About 6 weeks into the development process, we were doing a round of testing
to get a version out to Beta testers and found that we simply couldn't debug
the code and get it to 100% stable. That's when we dug deeper (yes, a bit late
for that...) and found that Appcelerator is essentially a VM running on top of
the native stack. So crashes get logged to the same few lines of Appcelerator
interpreter code--which is pretty much useless for debugging. For prototyping,
it's great, but for production quality code, I would say stay away.

Shortly before we finalized this decision, we reached back out to the other
firm whom we had originally spoken to before making the Appcelerator decision.
They told us that they were in the same spot and had just made the decision to
move off Appcelerator a couple days previous--for the same reason: stability
and lag issues and no way to get to zero defects.

We moved to native Objective-C and the dev team is much happier. Crashes have
full stack traces and we can identify exactly what to fix.

We got some benefit out of Appcelerator because the second round of
development took less time, but given the choice (and knowing that we weren't
just prototyping--we had a native Android app and we were generally happy with
the screen flows) we would have gone native to begin with.

~~~
neovive
Interesting. I thought Apple didn't allow VM's running on top of iOS.

~~~
whiskers
I believe the change in policy was that you can now implement VMs/scripting
engines but that /all/ of the bytecode/code that will run on them must be
packaged within the app (i.e. you can't download more code to run
dynamically).

------
ebiester
I've been working with Flex for the last few months, and I keep feeling that
"great" is not in Adobe's DNA. Adobe's DNA seems to be "Features! Features!
Features! Good Enough Features!"

I would kill for Adobe to go into each of their development tools and products
and spend a year without adding a single feature - instead, they just
obsessively make existing features better. Faster. Easier to use. Can anyone
mention an Adobe product they love? That they wouldn't like to see a more
elegant replacement? I include Photoshop and Illustrator in here, by far their
two best products.

Okay, so I'd like to also see a Flex->HTML5 builder, but if and only if it can
match the speed of their current solution. (And I'm sure they're working on
it.)

~~~
kreek
I've been a Flex developer for the last few years and you couldn't be more
right. Every time I dig deep into the framework and find something that
doesn't work I get the feeling some Adobe engineer knew it was broken but
their manager told them ship anyway.

My favorite lately was an Adobe plugin for Photoshop to export FXG files (FXG
is Adobe's SVG used to build Flex graphics). If you run the script it doesn't
even preserve text layers, it turns them into bitmaps instead. I could write
that script in an hour, why even bother releasing it as a half baked feature?

------
modernerd
If you want to build a native app, use the native development tools. I've yet
to see a third-party platform that offers 'support for building iOS apps'
result in good user experiences and positive reviews. Take these, from Conqu
for iPad (built with Flash Builder/Flex)[1], for example:

"App looks nice when it finally loads. Every function has a serious time lag
that makes the app unusable."

"However, be warned, this app is painfully s-l-o-w -- at least for me. So slow
it has been placed in the "tried apps" bin."

[1]: <http://itunes.apple.com/us/app/conqu/id440591468?mt=8>

~~~
smackfu
Someone decided to release these apps in that state, and it wasn't Adobe.
Furthermore, it was Apple's vaunted review process that passed these badly
working apps.

~~~
modernerd
Yet Adobe _has_ decided to feature 'badly working' apps in their showcase to
display what's possible with their tools.

My interpretation as a developer considering their software to build iOS apps
is that the apps in their showcase are indicative of what I'd be able to
produce for iOS with Flash Builder/Flex.

------
phatbyte
Yet another iOS builder....when will this end ? At the moment the only
reliable solution I see for building native apps without messing with ObjC is
(maybe) the future Macruby project. All these other solutions are just wrong,
and should end.

No matter how good they are they will always be one, two steps behind native
apps. It will be either for lack of documentation or unsupported new iOs
features etc..

To be honest, I'd rather build a web app for iPhone than use this stuff. At
least I'm being honest to my users and I'm not delivering crappy apps to them.
I mean, I understand why we need a standard tool, but this is the way to go,
running apps on top of VM is crap.

Sorry Adobe, not this time.

Edit: also, is really that hard to learn ObjC ? I find it to be a very easy
language to learn to be honest. Not the most pretty syntax, but it's easy.

~~~
christoph
Firstly, i'm going to agree with you - Yes, ObjC isn't that hard to learn and
people intending to distribute apps on the App Store really have no excuse for
not using it. If you want to use new features (Game Center, Notifications,
etc.) there is no better way.

Now I have to disagree with you... There is a use case for tools like this,
for me anyway - building small one off demo and kiosk type applications. I
built a "small" app for a customer the other day which was a menu with 7 or 8
videos linked from it and transitions between the menu and videos., with some
logging to say how many times people had viewed each video. Building this
natively in iOS meant messing with all sorts of API's, handling multiple
different scenarios that I really didn't and shouldn't need to care about and
generally consuming far too much of my time and the client's money.

Building the same application previously in Flex took me all of about 5
minutes and I suffered no performance issues whatsoever. If Adobe can deliver
me a tool to do the same on the iPad/iPhone, both myself and my clients will
be a lot happier for it.

Don't get me wrong, i'll still need to heavily weigh up what tool to use in
more complicated scenarios, but if Adobe can give me something to save time on
the smaller jobs (and it works), i'll take it.

------
NickM
Didn't Adobe try something like this already, and Apple changed their policies
to ban apps that used cross compiled code? Did Apple change their policies to
allow this kind of tool after all, or is this somehow different from last
time?

~~~
mambodog
Apple went back on that policy some time ago.

[http://www.techrepublic.com/blog/programming-and-
development...](http://www.techrepublic.com/blog/programming-and-
development/apple-relaxes-restrictions-on-third-party-tools/3119)

------
rb2k_
In the video: Did they actually speed up the "close up" recording to make the
applications seem faster?

They let audio track continue at regular speed, but the hand movements seem to
be at about 150% ... ouch

~~~
egb
I don't think so - I think the guy is just wired on caffeine :-)

Watch his hand movements when he's on screen - pretty frenetic IMO

------
neovive
Although, native apps will likely always perform better, I think this is a
step in the direction for small companies and startups that don't have the
resources to build and support mobile applications for all platforms. As
mobile platforms continue to evolve and change rapidly, the task continues to
get more complex.

Since Adobe has the resources and a strong vested interest in securing a
future for their Flash ecosystem, it will be very interesting to see how their
tools evolve over time. The market opportunity for tools supporting write
once, run anywhere mobile apps as well as tools for HTML5, Canvas, SVG and
WebGL development is clearly growing and Adobe is one of the few companies
capable of delivering this on a large scale. The question now is ... will they
do it?

------
programminggeek
You know I find that it is incredibly useful to use cross platform tools or
something like Appcelerator to test a proof of concept in the marketplace, but
in the long haul, it is a tradeoff and if you want certain features to work
right, you have to either be content waiting for the 3rd party platform to
support them, or you need to go native.

In general, there is nothing wrong with the strategy of build a basic v 1.0
proof of concept to see if it connects with a market and then rebuild it on a
native codebase. On the other hand, if you are a good enough developer, you
can probably skip this step and just start native, but that certainly isn't
the case for everybody.

Looking at Flash in this prism of being a cheap prototyping tool is a
reasonable way to look at things. Looking at it as a be-all-end-all platform
is a bit foolish, but most reasonable people outside of Adobe aren't that
foolish.

------
Hisoka
The combination of a steep learning curve (probably easier than ObjC but not
by much) plus the less than robust support for all of iOS features still makes
me prefer native. Make something as easy and simple as JQuery, and make it 95%
robust and I'll switch from native in a heartbeat.

