Open heymarkreeves opened 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?
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:
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).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.)https://github.com/jquery/jquery-mobile/issues/6990 https://github.com/kana/hatokurandom/issues/85 https://github.com/jquery/jquery-mobile/issues/6494
http://stackoverflow.com/questions/18996077/javascript-history-back-not-working-in-ios7
http://www.genuitec.com/support-genuitec/viewtopic.php?f=2&t=6999&p=24904#p24904
http://bugs.bizmodeller.com/view.php?id=146
http://stackoverflow.com/questions/18948373/why-is-uiwebview-cangoback-no-in-ios7
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.)
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?
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!
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.