I use the HTML5 app cache. I have tens of millions of users on this in-production product. I only really feel safe doing this because I have a custom web browser, and as I only target jailbroken devices I can hack at WebKit a little to make this work.<p>When I started using it, it seemed awesome. Then I played with it a little, and it started failing. Given that I have friends who actually give talks at conferences on the HTML5 application cache and how cool it was, this didn't make any sense: I believed I must be doing it wrong.<p>Then, one day, I decided to read the source code for WebKit's implementation of the HTML5 application cache, and found it to have tons of race conditions that would lead to whole-browser crash conditions (which I was even experiencing in my app). I even found a bug on the bug tracker with my most-occurred bug on it.<p><a href="https://bugs.webkit.org/show_bug.cgi?id=43506" rel="nofollow">https://bugs.webkit.org/show_bug.cgi?id=43506</a><p>Only, that bug had been filed only months before, and this feature of WebKit had been "in production", with these bugs, for a couple years. My only guess is that no one really uses this feature very often.<p>Reading into the bug tracker some (to find more bugs), staring at the commit messages for the previous year, and even reading some of the posts on the mailing list, I found choice quotes from the people maintaining it that explained that no one knew how this code works, and that the one guy who did forgot.<p>In iOS 4.3 (I believe it was only 4.3, not 4.2, but I'd sort of believe 4.2, /maybe/ even 4.1), the crash bugs have been "fixed" (or I'd have given them to comex to maybe build another jailbreakme.com), but the race conditions remain: the code doesn't actually /work/, it just sort of doesn't fail.<p>Specifically, the issue is that the application cache loader for a page is tied to a specific frame: the one that started loading the cache. If that frame is freed, such as by the simple act of the user hitting the reload button, while the download is occurring, the entire thing gets wedged, and you can no longer get any parts of your page cached, nor can you recover or fix the process without the user totally closing the web browser and reopening it.<p>In practice, this actually happens constantly: if the user has a reasonably slow connection, and things are taking a while in the background to cache, they will hit reload. This deletes the old frame, but associates a new frame with the same cache builder. When the current download stops, the frame it was using is gone, and it ends up in this horrible wedge state.<p>Ok, I no longer even remember why I'm bothering to type this here (does anyone care? does anyone actually intend to try to use this feature? ;P), but I also no longer seem to have anything more to say, so I'm going to click "add comment" ;P.