iPhone web application behaviour
The 'state of the art' for iPhone apps is a single URL, serving a static page with lots of JavaScript and Ajax. Clicking (touching, whatever) things loads in fragments and changes the page. IUI works like this, Hahlo works like this, the Facebook app works like this (hence IUI's behaviour).
To preserve state, normal usage is to use the URL fragment to add bookmarkability and history. And sometimes, this actually works. But given that the point is to pretend to be a native iPhone application, it's wrong. You should be storing state in cookies.
Justification: Native iPhone apps act like you never quit them. Even if they get closed by the system at some point, they'll come back to the state you left them in. Bookmarking a rich web application should act the same - I want to bookmark the application, and have it open in the state that I left it, not the state that I bookmarked it in. So you should update the 'current state' in a local cookie every time to navigate somewhere, and respect that state when you next visit the application. Combine this with the 1.1.3 firmware's webclips thing and you can almost pretend to be native.
Which is why I expect the much-anticipated iPhone SDK to be nothing more than 'local web applications'. Give developers a little bit of local storage (you know, like webkit just got), a way of promoting a bookmark to the home screen (we have that one now) and a way of storing some HTML and JS on the phone, and Jobs can claim he's given us an SDK. And he'll be right.
Me? I'd be happy with that. It solves all the sandboxing, security, 'bring down the network', etc problems. And it will keep people from jailbreaking the phone trivially. The only alternative I can see is installation of signed apps only, with the iTunes Media Store as the single point of installation. Which would suck more. But there will be howls of outrage.