Cache-busting in homescreen apps

heymarkreeves commented 9 years ago

We removed the appcache manifest because of an iOS7 Mobile Safari bug that broke browser history (back button navigation) when the appcache manifest was present.

That may have been fixed in iOS 7.1.2, released early in July. We'll re-enable and test with that version. If the issue remains, I'll follow up with more details.

desigonz commented 9 years ago

Hi Mark—just a quick question that Liam and I were wondering yesterday and might relate to this point. If/when caching works for the homescreen app, will users be able to use Artbot, exit the app for a bit (say, to write a text message or answer an email), and then, clicking on the homescreen app icon, be able to return to the same location on Artbot?

heymarkreeves commented 9 years ago

Hi, @desigonz, @jamiefolsom, and @mailbackwards!

Before proceeding to scope efforts on the HTML5 appcache, we need to put this in your hands for a verdict. Let us know what you think. Thanks!

While working on app integration for the MVP, we agreed to push out some issues with the appcache and iOS homescreen apps for a later phase. Revisiting these issues has been included on our Phase 1.5 list, and we've been doing some advance work to figure out where we're at and what our options are. Those options are not great, and we need to put the decision as to what to pursue in your hands.

If we leveraged no other features in the HTML5 appcache, we sought to include a cache.manifest for 1 reason: iOS aggressively caches the web app as a homescreen app unless it sees an update to the manifest file, which we accomplished by incrementing a version number. Without including this, we'd have no way of ensuring that users of the web app in a homescreen app would access updated files, whether those files be HTML, JavaScript, CSS or images. A bug or critical issue could persist in a user's homescreen app without using cache.manifest to force a refresh.

Doing so, however, introduced us to an iOS 7 bug, widely documented and a source of universal frustration. When a cache manifest is specified, browser.history in iOS 7 Mobile Safari breaks. This becomes evident after you load the homescreen app a second time, after it's been cached, and begin navigating through Artbot: The in-app back button ceases working. Our search for answers began in the jQuery Mobile community, but this is an issue that lives beyond our platform. It affects any mobile platform that relies on browser.history to implement back buttons in a homescreen app.

I encountered one post claiming this was fixed in July's 7.1.2 update, which is what I'm running. We restored the cache.manifest yesterday and tested again only to encounter the same issue. I suspect the user who posted that it was fixed did not test beyond the initial caching of the app.

Where does that leave us at present? If we encourage users to add the web app to their homescreen in iOS, at present we have a choice: Do we risk those users accessing an outdated codebase by omitting cache.manifest? Or do we offer iOS 7 users, currently 35% of the iOS audience [https://developer.apple.com/support/appstore/], a broken app in homescreen mode?

Neither of those are great options, but the third option is also a challenge. On this item, we'd need some open-ended time (budget) to explore other options. "Other options" would likely be limited to building our own history of navigation links in JavaScript, effectively taking over control of the back button. I'm confident this would incur significant time on corresponding JS logic and testing. (Note that we have considered traditional cache-busting tricks, like adding querystrings to CSS & JS file references, or letting Grunt generate new filenames each time and dynamically update their reference in HTML files. It's likely this would not work, though, because the HTML referencing those files would be cached as well.)

In summary, we'll need you to decide which direction you'd like to pursue. Our 3 options are:

Continue to omit cache.manifest, which breaks our ability to force a refresh of a homescreen app in all versions of iOS, where web apps are cached aggressively (and sometimes mysteriously).
Include cache.manifest, so we can reliably force a refresh of cached apps by incrementing a version number, as well as explore other options to leverage the appcache, but break the back button for iOS 7 users, still at 35%. That 35% number is not diminishing as fast as iOS 6 did, due to complications in the rollout and limited space on devices. (I've yet to upgrade my iPhone 5c for this reason, which has proven beneficial in being able to test iOS 7 issues.)
Incur significant time exploring and/or implementing workarounds. We're happy to estimate this better if you'd like to pursue this, but we cannot guarantee a fix short of building our own JS-based history.

Documentation of the issue and options we've explored:

While it's possible to run script based on full screen mode, this would run after the HTML element was loaded with the appcache manifest tag, at which point we couldn't modify the HTML element. And the appcache manifest tag needs to be present before the user adds the app to their homescreen. That's the point where it's registered.

http://www.bennadel.com/blog/1950-detecting-iphone-s-app-mode-full-screen-mode-for-web-applications.htm

Cited the issue, but not a fix - It only worked in "debug mode."

http://bugs.bizmodeller.com/view.php?id=146

Fix? UIWebView only

http://stackoverflow.com/questions/18948373/why-is-uiwebview-cangoback-no-in-ios7

Apple's documentation on appcache:

https://developer.apple.com/library/safari/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html

heymarkreeves commented 9 years ago

While I've been told that Apple frowns on approving App Store apps that are little more than a WebView shell to a website, it may be worth considering putting a wrapper around the web site as an iOS app, with some of the goals in #53 as factors. (An iOS app would be addressable from an email if installed, I believe. A homescreen app likely would not.)

desigonz commented 9 years ago

Hi Mark—thanks for your research into this! We'll regroup once Liam is back in town (tonight) and let you know our thoughts. When would you ideally like a response?

heymarkreeves commented 9 years ago

When would you ideally like a response?

I think we're getting close to putting a budget on the other items, which can be tackled independently of this decision. Once you have a verdict here, we'll figure out next steps for you to review. My plan is to get summarizing the other items as details are complete, put a budget on those for your review, and get a timeline in your hands. Just let us know what you're thinking on this item or if you need additional details.

Thanks!

clearbold / artx