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."
Could you expand on your position regarding the relative cost of developing a native vs. flash application?
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).
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.
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.
AIR and Flex have reputations for being slow even on desktops. It's just like Java on the desktop - yeah, it probably can be used to make nice-feeling stuff, but there's something going on with either the dev tools, the VM, the culture, or something that seems to make these apps tend to be, more often than not, really unpleasant.
The Unreal Engine is written in C++, however, which counts as native code.
(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.)
Yes, but I think you missed the point... I was talking about how the Unreal Engine uses a third-party development environment, makes portable content but some of their games are huge success cases on iOS. Basically I was replying to this: http://news.ycombinator.com/item?id=2674382
It is also important to note that the library encompassing the AIR for iOS Runtime seems to be very large and cannot be shared across apps, making over the air downloads more painful (20mb cap typically applies for 3G OTA)
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.
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?
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.
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).
Apple changed/clarified its policy to allow VMs and scripting languages, so long as all the bytecode or script is built into the app you submit for approval. Adding more script after the app is installed on the device is not allowed except for the built-in WebKit Javascript engine.
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?
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.)
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?
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.
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.
I've "learned" Objective-C, but I would not call it easy. Moreover, it's not just the language, but the entire toolchain: neither XCode nor Cocoa are intuitive to new developers, whether they have experience in other platforms or not. IMHO, it fails the first half of "easy things should be easy, hard things should be possible".
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.
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.
31 comments
[ 2.5 ms ] story [ 59.6 ms ] thread"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
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?
http://unity3d.com/
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
http://itunes.apple.com/us/app/munitracker/id436932756
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.
http://www.techrepublic.com/blog/programming-and-development...
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.
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?
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
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?
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.