3 Things Apple Could Do (If They Really Supported HTML5 iPhone Apps)

Apple's made a big push against Flash/Flex, which is what many would call traditional Rich Internet Application (RIA) development, in favor of HTML5. One can argue the merits of their points, but one part that is somewhat confusing is rather significant gaps which makes it difficult to make HTML5 behave in way that would really allow it to compete with native apps on the iPhone (and iPad).

While you can certainly argue that none of the following are "pure" HTML5 - let's not pretend that the iPhone in particular is a pure HTML5 platform to begin with. Mobile Safari is a great browser, but has some very specific quirks to it. Whether it's the way pages are rendered in their entirety outside of the viewport (which makes, say, creating fixed bottom elements difficult) or that there are unique touch events outside of the normal mouse event structure, developing for Mobile Safari forces the developer to go a little outside the web standards. Apple does provide some useful features, though, like sending numbers over to the phone or linking to the Google Maps app - but they could do a lot more for both the user and the developer.

1. Camera Access
This is really the big one. There is no way to access the camera via pure HTML5. Cocoa based frameworks like PhoneGap attempt to bridge the two, though I've been told that getting PhoneGap based apps onto the normal App Store has been difficult. Being able to utilize the camera is an oft requested feature for business and productivity apps. The first app our company submitted to Apple used it to store images of receipts, for instance. Scanning bar codes is another common request. Apple provides zero interactivity between the browser and the camera - not even giving users the ability to browse into their photo albums.

2. User defined database limits
There is a hard 5 MB limit for offline database storage via HTML5. In most desktop implementations, this is something the user can easily override. While five megs is sufficient for many tasks - there are many where it simply won't work, like storing offline media assets within the database or even attempting to store a complete product directory in some instances. While having standard limits makes plenty of sense, if a user wants to up that limit to 50 or even 500 megs, they should be allowed to do so. I've got 32GB on this phone, and if I want to shove 1GB of product data into it via a web app, I see no reason why Apple shouldn't let me.

3. User friendly controls
Currently working with iPhone web apps is a somewhat hacky affair. Most users don't associate "adding to the home page" with the same notion as "install this app" (hence the reason many web apps are now adding a big arrow pointing to the plus sign for the iPhone) - nor is there any indication if that app is available offline, etc. Apple still maintains its web apps directory, but that's a poor offering compared to the App Store, Apple Store and iTunes Store apps. I could forego a web app store app (sorry for the redundancy there), but users should at least be able to go to one place and see which web apps are installed, what data is stored offline, and check for new versions. Google is moving in all of these directions with Chrome - and to a certain extent shows how serious they are compared to Apple in truly getting people to adopt web apps as a serious platform.

That third one is a luxury - the first two, however, I can report is somewhat crippling the iPhone and iPad as a robust platform for web application development. Apple can produce fancy CSS demos until the day is long, but if they really see HTML5 as the future, then they should give developers the tools to make it so.