I suggest you revisit the handheld arena with an open mind in 2008. Some things still apply, but with bigger screens, always-on internet connectivity, and built-in web browsers that support full html and sometimes flash and ajax, handhelds are trending towards relying on web apps for mobility and extensibility. A web app should be the first mobile solution for a handheld because it is cheaper, easier, less wasteful in development, that also allows you to easily track statistics about which apps and features are being used, and how.
Then you can create a native version for the blackberry and iPhone to take advantage of one of the two things I believe make a native app advantageous at a later point in time:
1) synching the handheld's data with your web app, or
2) saving data to access if you're without an internet connection.
As far as GUI elements go, the iPhone lets you make your program look like a native application.
As far as speed of access, launching an app on an older treo model would take at least 2-5 seconds, especially a database application. You can load a web page over Wireless-G in today's handhelds in that time.
I think that your statement that you should build a web app first is absolutely correct: as long as you assume it will be the 'one to throw away' (http://everything2.com/index.pl?node_id=1011623). It will be a toy application and barely a proof of concept.
I've personally replaced dozens of those systems.
I believe that there are differences that are specific and salient to handheld devices that are still quite relevant today.
1. Processor Speed / Battery Life / Energy Density
Moore's law does NOT apply to batteries; they increase in capacity at about 3-5%/a. This means that the limiting factor on processing is NOT the processor, but the energy you can feed it (and that you can wick away as heat). Cutting edge handheld processors are still at about 400-600MHz and have been stuck there for many, many years.
2. Browser complexity and inefficiency
This is related to the first point. Browsers are among the most complex applications that run on desktops and handhelds. They tend to eat up obscene amounts of memory and use a lot of clock cycles interpreting languages (CSS, HTML, Javascript, Flash...). This chews through the available (slow) processing available on handhelds. You could limit what you use, but AJAX and its ilk are part of what make a web interface workable.
3. Security
This may only be relevant to the work I did in Healthcare. While I trust the SSL implementations, I don't trust the caching implementations on Handheld browsers. Given that these devices get lost, do you want to be liable for confidential patient data stored on them in a format that isn't under your control? Want to encrypt it with some clever javascript in the browser? See points 1 & 2.
4. Diversity
Developing for IE6/7/8, FF, Opera and Safari is one thing. Adding the proclivities of the browsers on the iPhone, WinCE, PalmOS (where there are several), RIM, and all other smartphones will make you go bald. Now imagine testing on all of them as well. The issue is more interesting. If your marketing dept gets wind of the fact that it works on a mobile browser, you're suddenly flooded with support calls the moment a new fancy phone appears on the market.
5. Novel User Interfaces: beyond the G in GUI
One of the cool things about these phones is that they have neat UI things to take advantage of: the 5-way scroller on the Palm, the rocker switch on the RIMs, multitouch on the iPhone, fingerprint, passcard and barcode scanners on some specialized devices. NONE of these are under your direct control if you build a web app. You're at the mercy of the common set of UI made available across the browsers and how each of those browsers interprets the gestures.
6. Constant connectivity
Again, this may be due to my work in the medical field, but I was shocked at how many installations were crippled do to lack of building-wide WiFi or huge dead zones. Like ALL of radiology. Or the entire wing that was put up in 1948 where the internal walls were plaster on chicken wire. Even looked at the size of chicken wire? Ever compared it to the wavelength of a 2.4GHz signal? It'd be hard to block signal more
effectively. And if you're moving around a list of 14k ICD codes or 7k CPT codes, you're going to need that pipe to stay open.
Now, having ranted, lets look at the world as it stands:
- why were developers up in arms over the lack of an iPhone SDK?
- why isn't Android just a set of javascript libs?
- why are are ALL apps on the RIM fat, local applications?
- why did Google invest time/money/effort into creating local Java implementations of Maps and Mail?
- can you name a single, widely deployed mobile app that's purely on the browser?
I think the world has changed, but not nearly enough.
Then you can create a native version for the blackberry and iPhone to take advantage of one of the two things I believe make a native app advantageous at a later point in time:
1) synching the handheld's data with your web app, or 2) saving data to access if you're without an internet connection.
As far as GUI elements go, the iPhone lets you make your program look like a native application.
As far as speed of access, launching an app on an older treo model would take at least 2-5 seconds, especially a database application. You can load a web page over Wireless-G in today's handhelds in that time.