Web Apps Versus Native Apps

Apple announces iPhone SDK! Hurrah! Holy Crap!

Apple has announced that they will have an SDK available for the iPhone and the iPod Touch in February 2008, and I think that it’s great, great news. Although I have my own opinions on the matter I have by and large tried hard to stay out of the bitchcraft most people have been practicing about Apple’s previous “sdk” (web applications in MobileSafari) because:

  • The kvetching of a bunch of nerds honestly has very little impact on a product that is selling like hotcakes.
  • The iPod has, up until this announcement, always been a closed platform. If the iPhone is a much snazzier iPod with a built-in phone, there seemed to be no compelling reason for Apple to to change their stance on it, either.

Really, the fact is, Apple doesn’t have to do this at all. The fact that they *are* going to release an SDK is huge. HUGE. Take a moment and just savor it. They have a ridiculously lucrative product. It doesn’t need 3rd party applications to sell well. Nerds are unhappy, but it will still sell just fine anyway. Nonetheless, they’ve decided to go ahead and do it. Whoa.

Native Apps Versus Web Apps

My company has an aspiring web service conceived as a GTD tool for teams called Mentat. I have crazy ideas all of the time and basically need to be able to capture them or update them where ever I am, at any time. I know that I’m not alone on that, either (writers, entrepreneurs, business owners, and others all have to deal with this kind of thing). I also own an iPhone, so as soon as Mentat was online I started working on a web interface that would let me access my task lists while I was on the road.

I immediately ran into a ton of short comings, but just tried to deal with them as best as possible. I recently started working on a native Mentat Client for the BlackBerry, and the native application’s superiority for this kind of thing are really leaping out at me.

It is all about connectivity

When I initially started testing out the iPhone interface, I did most of my work over our local wifi connection, and things seemed really good. Mentat uses a lot of Ajax and dynamic user interface elements, and most of them worked well in MobileSafari. I was really excited about how things looked and eagerly sent around links to my other friends and associates with iPhones, and got excited responses back from them as well.

The first heavy use I made of the interface was during grocery shopping: my wife would call me with a honey do list on the phone and I’d blast everything into Mentat through my Macbook Pro’s browser. Then, on the way home from work, I’d stop at the grocery store, whip out the iPhone and start checking things off.

Everything ground to a halt. I was off of the wifi network and running on EDGE for the first time. Performance went from brisk and sporty to unusably slow and frustrating. At first I chalked it up to a shitty connection in the grocery store, but that didn’t wash. Page updates were agonizingly slow (on the order of 30 seconds in most cases) no matter where I went.

This isn’t just due to EDGE’s lower bandwidth. As I learned while working on Pulse, EDGE networks have a really significant amount of latency. This results in a sort of holding-your-breath kind of pause before data shows up, even just surfing in MobileSafari.

It didn’t take long for me to realize something pretty vital here: built-in wifi is great, but 90% of the time, if I’ve got wifi access, I’m also sitting down in front of my laptop. Most of the times that I use the phone instead, it’s because I’m on the road somewhere, or at the store, or having lunch at a place that may or may not have wifi. Bottom line: applications like ours have got to crank along merrily at EDGE speeds or they just aren’t going to cut it.

The main problem ended up being Javascript. Lots of it. It turns out, that even compressed, it can take about 20 seconds to download all of the Javascript we use on an EDGE connection. Most of that Javascript was in place so that we could use AJAX and avoid doing complete form posts every time we changed a bit of data here or there.

Irony

Most of our AJAX code was intended to make updating tasks quick and reflexive. Ironically, downloading the Javascript libraries that provided use with this functionality took a lot longer than anything else we were doing, so we ended up totally rewriting the iPhone pages to use web 1.0 static data and form posts. And it got a lot faster. There are still areas that we can improve and functionality that we need to bring to the iPhone interface, but right now, you can review tasks, add tasks, and close tasks quickly. Leaving a comment takes longer and other features just won’t be available right now.

Lessons learned from working on the Mentat BlackBerry Client

In the meantime I’ve been working on another client for the RIM BlackBerry family of devices. These are basically just J2ME applications with some additional platform specific code provided by RIM. The feature set for the BlackBerry client isn’t complete yet, but here is a list of all the things that we get using a native application instead of a web application, and what I am now hopeful that we can deliver for the iPhone in February.

  1. You don’t have to download the entire application every time you want to use the service.
  2. This is pretty obvious, I mean, I recognized that this was going to be an advantage before we ever started working on it. But my god, this makes starting up and changing screens *fast*.

  3. Data transfers are much faster.
  4. This is pretty much the opposite side of the coin of #1: all the code for a particular screen is already on your phone. The only thing we have to download now is data from the server to make what the screen shows you more interesting.

  5. We can cache that data.
  6. As with blogs, most of the time when you look at Mentat you’re only looking at one of a few different HTML documents. What changes as you browse from project to project is the data set that the page is showing you.

    One ugly consequence of the iPhone’s web application model is that the entire page and all of its data is downloaded every time you look at it. Switching back and forth between projects becomes agony, because each switch takes several seconds, partially due to EDGE bandwidth and also significantly due to EDGE latency.

    The new native client has a centralized data store that holds information for all of your projects. When you first view a project it will download all of the task data for it and then store it in the cache. The next time you come back to the project, it loads the data out of the cache instead of having to download it from the server. If you want to see if anything has changed on the server, you can refresh the view. In the near future the client will periodically check for recent task modifications instead of refreshing the entire project, which will make updates automatic and unobtrusive.

    Using the cached data, particularly for single user projects that are unlikely to change in the background, is almost infinitely faster than reloading the page over EDGE. It seriously rocks, so much so that I’m thinking about shelving my iPhone for awhile over it. Or at least starting to hack a native client early…

  7. You can work offline.
  8. This is something that a lot of our customers have been asking for. With a native client it is pretty easy: even if you can’t connect to the server at the present you can at least start creating or editing tasks offline. Once your connectivity is restored we can push your changes back out to the server for you.

    Alternatively, with an iPhone web app you are totally dead in the water, as you can’t even load the page that would be showing you the data.

  9. We can store your login credentials and automatically log you in every time without a hitch.
  10. This is also a pretty big deal. The Mentat server, like many others, stores one login cookie for you. If the last device you used to log on was your iPhone, you’re in good shape. If it was your desktop machine, you’re going to get a login prompt again and have to enter your information again. We know how to fix this but haven’t had a chance to take it on yet.

    By storing your login information in persistent storage on your phone, we can bypasses all of that and just automatically logs you in using your regular user name and password. It makes starting up quick, and its a nice change from the iPhone interface.

  11. You can receive notifications while the application is in the background.
  12. If you are in a Teams or Group project, this will be great - you can receive task overdue events, new task notifications, or comment events in the background, while your phone is holstered.

  13. Alerts
  14. This goes hand-in-hand with the previous feature. An alert will let you know as soon as someone has commented on a task you have assigned them, or when someone has assigned an item to you. The fact that this can totally bypass your spam-ridden email account is even better. You know that the alert is relevant.

  15. We can start up automatically when you turn your handset on.
  16. As soon as you power on your phone, your device can start tracking your application events for you.

Most of this may seem fairly obvious, but it seems like five months of web app-only iPhone experience has made these things seem like mad, impossible fantasies. I’m looking forward to making these features available to the iPhone and the iPod touch soon and I’m grateful that Steve Jobs and Apple have decide to make that a legitimate possibility.

Technorati Tags:
,
,
,
,

One Response to “Web Apps Versus Native Apps”

  1. hosthg » Blog Archive » Web Apps Versus Native Apps Says:

    [...] check the full story here [...]

Leave a Reply