> We know deep inside that HTML5+JS+CSS is where the future is going.
When I compare the state of the tool suites for HTML5+JS+CSS to XCode, I can't help but think of Visual Basic 4. In my opinion, Visual Basic 4 was the first tool that made it easier to build and test GUI-driven database apps. In a similar manner, XCode is the first tool that makes it easier to build mobile apps. It doesn't hurt that Cocoa is such a well-designed framework. From the recent articles about Android development experiences I've read (UI building in Android being an unholy mess of GridBagLayout and XML), it appears Apple still has the best-in-class tools for mobile development. Yes, it is a closed market, the AppStore. However, unless you have a top-200 app, it's likely your customers will find your app by searching for it, not browsing. This is highlighted by the recent change that makes keywords mandatory for app submission.
Until HTML5+JS+CSS is easier to develop, I believe mobile development is going to favor the iPhone SDK because it makes it easier to get something together.
I fully agree, but I also think Apple is moving in that direction with Dashcode, although it doesn't really provide the full functionality of Xcode+Interface builder.
I think, the time when HTML5+JS+CSS will become everyday for small apps is the day when there are some robust UI frameworks. We are moving in that direction with the different frameworks, e.g. Cappucino [http://cappuccino.org/].
In the meantime you can take a look at Qt Quick [http://blog.qt.nokia.com/2010/02/15/meet-qt-quick/]. It uses a declarative language, called QML, for defining UI and the app logic can be either JS or hooked into Qt objects written in C++. I've only played with it a couple of days, and already I am sold on the possibilities for rich animated fast UIs.
It seems a lot of development time, especially early on, is consumed with debugging and fitting pieces together properly. What is your impression so far of the ease of debugging (not on hardware, the simulator)? XCode's Instruments and their debugger are tools I've only started getting more out of using.
When you talk about debugging with a simulator I assume you are thinking about targeting a mobile device, so correct me if I'm wrong.
One of the strength of Qt when developing for mobile devices is that you can develop your app on the desktop and debug it there (to a point), and then deploy to the device and tweak. Of course, when you start using device specific features you will have to go in hardware or a simulator.
At the moment the EPOC emulator which comes with the Symbian SDK leaves a lot to be desired. Many of the phone specific features (like sensors or location) are not supported, so you will have to goto hardware for those anyway. Unfortunately, I don't know what the plans are with regards to simulator for Symbian.
That said, debugging in target from Qt Creator is quite often nice. The problem comes when Qt Creator simply says that you have a Generic OS related error, then you are pretty much stuck.
Make that "HTML5+JS+CSS is easier to develop" and "the devices are faster". Much of my consulting work is making iPhone apps faster. People seem to forget that the iPhone and iPod hardware is slow and has limited memory. I'd imagine the equivalent Android/etc hardware is about the same.
That said, if the iPhone/iPod/iPad drive mobile CPUs forward the way the iPod drove battery technology, then there's an exciting future of powerful handheld devices not that far off, and HTML5-based mobile apps will be a lot more competitive.
I agree to a limited extent with his point of, "It is convenient for us amateur devs to be able to focus on development and let Apple take care of all the things we hate most: distribution, payment processing & a little marketing."
Developers want people to use their stuff but the effort of marketing and selling it isn't fun. The complete truth is in the article as well where he mentions all of the ways they don't market your app for you (i.e. the buggy New Release page). So yes, Apple handles distribution and payment processing but don't count on them for marketing.
This is a really silly reason for people to develop for the iPhone.
Yes, you can use the App Store to your advantage if you work at it, but you really should think of it more as replacement to the "download" link you'd have on a desktop app site. It's best to market things like you would on any platform (web, desktop, or otherwise) and spread the word. Just because it's an iPhone doesn't make it magical.
It does drive down your costs compared to web site - you don't have to explain it to as many people, they do a reasonable job at copy protection and they handle billing.
That is something I never understood about the AppStore: there's no way to set up a decent sales funnel. Once you redirect the user to iTunes you lose all tracking capabilities. If they can't provide basics like that, I think PPC ads are a long way off.
Even some basic analytics would help: How are people finding my app? What are they searching for? What web sites did they come from? What languages do they speak? etc.
When I compare the state of the tool suites for HTML5+JS+CSS to XCode, I can't help but think of Visual Basic 4. In my opinion, Visual Basic 4 was the first tool that made it easier to build and test GUI-driven database apps. In a similar manner, XCode is the first tool that makes it easier to build mobile apps. It doesn't hurt that Cocoa is such a well-designed framework. From the recent articles about Android development experiences I've read (UI building in Android being an unholy mess of GridBagLayout and XML), it appears Apple still has the best-in-class tools for mobile development. Yes, it is a closed market, the AppStore. However, unless you have a top-200 app, it's likely your customers will find your app by searching for it, not browsing. This is highlighted by the recent change that makes keywords mandatory for app submission.
Until HTML5+JS+CSS is easier to develop, I believe mobile development is going to favor the iPhone SDK because it makes it easier to get something together.