iPhone Web App Development: JQTouch vs Dashcode

I’ve been playing around with iPhone and iPad web app development for the past week or so (I’m working up to building a native app, as there are benefits to playing both sides of the field here). Given my familiarity with jQuery, I felt inclined to try out the jQTouch framework to start with. After some successes and failures, I then decided to take Apple’s Dashcode development environment for a spin. Here are my initial impressions:

My adventures began by modifying the demo jQTouch application to do what I wanted. I was impressed by the capabilities of this framework out of the box. It looks good on both the iPhone and the iPad – and feels just like a native app. The user can add the page to their “home screen” to load it up just like a native app also. My first stumbling block came when I faced the iPhone’s “no multi-tasking” limitation. If the user spent some time browsing to a particular place in my app, then left the app for any reason (e.g. to take a call or check their email), then they would be sent back to the start screen of the app and lose where they were altogether. I tried a number of workarounds the involved things like local storage, session storage, cookies, sessions and the like, but all were a little klunky. I realize that this problem will be fixed in iPhone 4 with the advent of multi-tasking, but many iPhone’s don’t qualify for this upgrade so it was important to me to at least be able to retain state.

Rather than hack jQTouch to pieces to try to implement this functionality (believe me, I tried), I decided to see what else was on the web app development landscape. That led me to Dashcode.

So I started the project more-or-less from scratch using Dashcode. I was impressed most by the Dashcode interface – how it allows you to drag and drop GUI widgets, or code snippets. It really is a model to follow if you want to develop an IDE. With Dashcode, you are almost completely insulated from the HTML markup. Instead you work with the visual WYSIWYG pallettes or with the javascript API to update the model. Rendering is done using MVC, and the performance of the resulting app is noticeably (on my older iPhone 3G) snappier than with jQTouch..

Unfortunately, I ended up hitting the same wall as with jQTouch: saving and restoring application state is a bit of a bitch. It involves more than just recording “where you are” in the app, because of the way the “back” buttons are set up, you have to recreate the entire environment, history and all. This is more than I really wanted to do right now.

So at this point I had 2 nearly complete, and almost identical apps. One using jQTouch. The other using Dashcode.

But now that I had climbed the learning curve in both of these frameworks, I knew I could do better. So I started, more-or-less, from scratch with a new project using jQTouch that will incorporate all that I had learned. I’ll be releasing the app in a few weeks.

Here is a brief comparison of these two ways of building iPhone/iPad apps:

  1. Dashcode produces an app that is a little snappier and a little more native (on the iPhone).
  2. jQTouch seemed to allow me more flexibility since I have direct control over the markup. In addition the development cycle seemed to be a bit faster using jQTouch. (However I’m sure you could improve the dev time on Dashcode if you used jQuery and other productivity libraries on the javascript side of things… I had been trying to use its API directly).
  3. Dashcode doesn’t seem to scale up to the iPad larger screen as easily as jQTouch. The extra flexibility in jQTouch with markup etc, makes me feel better equipped to customize the interface for the device.
  4. Dashcode is a fantastic IDE.
comments powered by Disqus