This blog lists the difficulties and drawbacks faced when using the Application Cache. Solutions to most of these issues are described in another article called Tips for using Application Cache?
- Double Refresh Issue - This is perhaps the biggest problem with manifest files. If the content for the page has been updated, the user will view the old content that was in the Application Cache until it has been updated. However, the
Application Cache is not updated until the user views the page, as shown in the diagram below. This ultimately means that when the manifest file is updated (triggering the Application Cache to be updated) the user will not see the new content until they
view the page for the second time. After content has been updated, the first time a user views the page they will view the old content loaded from the Application Cache. In the background the Application Cache will be updated and will
receive the updated content. The second time a user views the page they will see the updated content. This is particularly problematic if not all the page resources are in the Application Cache. For example if a manifest file is "open"
(as it has a * in the NETWORK section), any resource not listed in the CACHE (or FALLBACK) section will not be stored in the Application Cache. These resources will be downloaded freshly every time the page is viewed
normal caching rules apply for Browser Cache, Proxy Caches, etc). The user may, therefore, get fresh copies of any resources not listed in the manifest file and stale copies of those resources listed in the manifest file until they refresh the page for a
- Atomic - Once a file is cached, the browser will continue to show the cached version, even if you change the file on the server. If you want to update a single file in the Application Cache, all files must be updated at the same time. Any change made to the manifest file will cause the entire set of files to be downloaded again.
- Internet Explorer 10 - According to Matt Andrews