Adobe Updates Flash Builder and Flex to Support Building iOS Applications
blogs.adobe.com
blogs.adobe.com
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.
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.)
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?
"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."
I'm not sure there are enough published Apps that have been produced with Flash Builder 4.5 to make a judgement on it one way or another yet.
I know I'll be downloading it and giving it a go - I don't mind Objective C but I'd rather be writing my code in other things!
Is it simply constrained supply? The limited number of Objective-C developers, or that native development requires a higher skill level, thus constraining the number of suitable developers, or ...?
(I'm not actually a firm believer in the above, I'm just throwing some brainstorming ideas out there -- I'm even ready to believe it costs less to produce a polished native app than trying to polish a webapp).
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.
>I've yet to see a third-party platform that offers 'support for building iOS apps' result in good user experiences and positive reviews.
Can you provide any apps that result in good user experiences as counterexamples? Or were you not disagreeing with him and I'm just reading you wrong?
Also the Unreal Engine, which is used on Infinity Blade.
(Although I think games are a different beast altogether. They don't have to adhere to any unifying HIG, and are fully justified in doing their own thing. It doesn't really matter what's underneath in that case, as long as it gets the job done.)
But I agree 100% with your second assertion.
From Conqu (for example). A 25mb tasklist app?
Free Category: Productivity Released: Jun 02, 2011 Version: 1.0 1.0 Size: 25.0 MB
MuniTracker for iPhone
Category: Navigation Updated: Jun 04, 2011 Current Version: 1.1.0 1.1.0 Size: 21.8 MB
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.
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.
Personally, I've gone the HTML5 route, both to leverage what I already know, and to maximize compatibility with as many platforms as possible. Though I can't do everything Cocoa can do, I can still do quite a lot, while still paying deep attention to the little touches of user experience. I don't blame Flash/Flex devs for wanting to do the same with their existing skills; time will tell how those toolsets fare in practice regarding UX and performance.
http://www.techrepublic.com/blog/programming-and-development...
They let audio track continue at regular speed, but the hand movements seem to be at about 150% ... ouch
Watch his hand movements when he's on screen - pretty frenetic IMO
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?
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.