I developed a small HTML5 app a couple of weeks ago, optimized for the iPhone (in Dutch): http://c.phanatics.nl/
It converts between track and field performances and awarded points by the Dutch athletics competition. The conversions can be stored. Intended usage is on the field during competition day, or just for the curious.
Originally I also used a manifest file for caching, but decided I didn't need it (and Firefox popups warnings with it). (The manifest is still used in SVN rev 20.)
The biggest problem I encountered on the iPhone (and have not been able to solve) is that whenever you switch apps and return, Mobile Safari reloads the page (online, or from cache) and does so using the original url. There seems to be no way to stop this.
For me that meant that stored conversions where lost (they were stored in the DOM and url), so I had to store them explicitely using localStorage. And still then, it is annoying you have to wait a few seconds for the page to reload before you can do anything.
The only info I found on this problem suggested that it might be related to Mobile Safari's memory management and as such wouldn't occur (as often) on iPhones with more memory than the one I tested with.
Personally I would only use the cache manifest, when I planned on using it as an app that is launched like normal. Also did you make sure all your files were less then 15k that seems to be the limit at which iphone will cache files.
Yea, this book was really helpful, and I can't belive I forgot to add the link to the article. For some reason though people still didn't know they could write apps like this. That was my biggest reason for writing this article.
Also, my startup (http://www.appstorehq.com) provides search+discovery for mobile apps, including mobile web apps. We're trying to push the boundaries with mobile web apps (e.g. easy, App Store style payments) and are looking for alpha testers.. If anyone is interested, email me: iseff@appstorehq.com
This is a great post and I'm glad to see someone do such a nice description of "doing it from scratch", but I thought I'd mention that Dashcode (part of the free developer tools for OSX - http://www.apple.com/macosx/developers/#dashcode ) has built-in support for developing iPhone Web Apps and includes some templates for the more common types.
It's a cool way to get an app up-and-running quickly without having to consider the App Store process and while it does abstract you a bit from the straight coding, it's all still done with HTML, CSS and Javascript so if you're already a web developer and not interested in learning Objective-C it's a nice tool to build something quickly.
I've developed several "native" iPhone apps but went this way for one project because we could do everything they wanted to do in a web app and it was simply faster to get there than if we did a native app.
Definitely one of the most overlooked options out there.
but its C—or a form of it—and it’s really hard to learn
I personally prefer Javascript to Objective-C, but HTML, CSS and Javascript are not easier to learn than Cocoa and Objective-C. Objective-C and Cocoa are very will designed, simple tools.
True - they're not easier to learn but beyond the browser they are more applicable across different mobile platforms (i.e. Android, Blackberry). Objective-C and Cocoa will always be iPhone specific. I've been learning Objective-C though I wonder if my time would be better spent on javascript/html/css and usage of environments such as Titanium developer or Phonegap.
Although it's not particularly common, there's no real barrier to using Objective-C on any platform that has a gcc port, since it's one of the supported front-ends. If you liked it, you could use it to make native Linux apps, in lieu of C or C++ or whatever else you might use.
Also, many many people already know JS/CSS/HTML, like me.
I picked up phonegap and had my first app on the store in a week of spare time. But then I rewrote it with Titanium because it was kind of slow, which took at most another day.
It felt like Christmas, and I found iPhone skillz under the tree.
But now I want in-app-purchase, so I'm learning Obj-C... so the above was all for nothing.
If you ignore the C part its pretty much like any other OO class based language. You send messages to objects. The message causes a method to be activated. The method can access / set instance variables and send messages to other objects. Quite similar to Ruby, Python ... etc.
Cocoa is also much simpler than the mess that is building applications using HTML, CSS and the DOM. It was designed specifically for the purpose that is used for, unlike web applications.
I don't think it would be all that difficult to learn the language of objective-c, but there is always more to learn the just a language.
JS, HTML, CSS, require a brower, and a text-editor. I don't see many people building iPhone apps outside of xcode. And that stack seems to work well, but when a person who spends a lot of time with the browser model of development, try the xcode way of development, there can be a shock sometimes. Its a metaphore change, that can sometimes be hard to wrap your mind around.
I also think it goes both ways.
I would also argue that your premise that HTML, CSS, and JS were not designed for web applications, is invalid, because we can't just look at technologies for what they were suppose to be used for.
Plenty of stuff has been developed for one thing, but ended up doing another.
It wasn't used because it was well suited for the task. It was used in spite of its limitations because it doesn't require software installation. This made such a huge difference in uptake, that it didn't matter that the user experience was inferior in many other ways.
If anyone else hasn't made an HTML5 iPhone app or any web app for that matter before and got lost at this part:
"Then, next step is to server it from an actual webserver that can set the proper settings on the cache.manifest"
then maybe I'm not alone? I'm assuming I just read it wrong and it means you can use the same webserver you are using to host your blog, website, etc.?
(edit) I do have one more question to add for all you crazy iPhone app and maybe Palm app developers out there: 1. Is there an straight-forward way to do this method and then use iPhone developer apps to bring it in and export it to then distribute via iTunes App Store? 2. Same question about Palm.
The HTML5 Spec actually has a nice explanation of how to do the manifest. You can find it here: http://bit.ly/aLbKP0
I wrote a blog post a while back that talks about how browsers handle the manifest files. Forgive the shameless self-promotion, but it might be interesting background reading: http://bit.ly/9WhsO8
Basically, the manifest file is just a special text file that stores a list of the things you want the client to cache. This is the feature of HTML5 that enables offline access to web resources. Think of it as sort of a robots.txt for caching purposes.
Needs to be a web server you have enough control of to set caching headers for the files in question. If you have enough control of the web server hosting your site, blog, etc., that's fine.
For iPhone it's dead simple to turn an HTML5 app into a native app to get into the app store (see Bank of America's banking app which is HTML versus Citibank's app which is native). There are even kits to help with that: http://www.tuaw.com/2009/05/27/nimblekit-native-iphone-apps-...
The point of an HTML5 app is that (a) you can use DHTML+JS to develop it, and (b) you can bypass the app store to deliver it.
My opinion is mobile safari is still too slow for this. I did one and it was fine in the simulator, but lagged on iPod touch. 3GS was mostly ok. Maybe in a generation or 2.
Keep at it. I seriously dove into it about three months ago. Objective C/Cocoa is no longer the problem, it's the solution. Don't worry if the code you write sucks when you look back at it (e.g. no categories, protocols, NSNotification use). Interface Builder has a thick skin; curse at it. Part of learning this is learning the non-optimal way first. You'll grow into it. The best part of Cocoa/Objective C is how well it was designed. Highly recommend "Cocoa Design Patterns".
Currently going through this one. Seems pretty solid for people that already know their way around UI. Haven't found anything obviously wrong like in some other iPhone books I looked through.
I was just thinking about if a webapp could setup a protocol handler, similar to the way Tweetie uses "tweetie://" in its Mobile Safari bookmarklet. I wouldn't mind using something like Notifo to push notifications to my users but it's unclear how my offline webapp could be launched from the notification.
It converts between track and field performances and awarded points by the Dutch athletics competition. The conversions can be stored. Intended usage is on the field during competition day, or just for the curious.
Source: http://svn.vermaat.name/competitie-rekending/
Originally I also used a manifest file for caching, but decided I didn't need it (and Firefox popups warnings with it). (The manifest is still used in SVN rev 20.)
The biggest problem I encountered on the iPhone (and have not been able to solve) is that whenever you switch apps and return, Mobile Safari reloads the page (online, or from cache) and does so using the original url. There seems to be no way to stop this.
For me that meant that stored conversions where lost (they were stored in the DOM and url), so I had to store them explicitely using localStorage. And still then, it is annoying you have to wait a few seconds for the page to reload before you can do anything.
The only info I found on this problem suggested that it might be related to Mobile Safari's memory management and as such wouldn't occur (as often) on iPhones with more memory than the one I tested with.