iOS 6.1.2 caching issue

Tags: iOS, Safari, iPhone

Recently I had a great deal of pain with our mobile web application on iOS 6.1.2 (and higher), which seemed to be caching some content forever.

As most of our customers own mobile devices we're offering our business via a mobile website that's compatible with a wide range of phones and tables; for the iPhones we offer the possibility of bookmarking the application to the homescreen (also known as a standalone web app); the bookmark will then trigger a chromeless instance of Safari (via the apple-mobile-web-app-capable meta tag) which I gues is what triggers the behavior described below.

About three weeks ago we started getting some support calls from 6 of our customers stating that when using the bookmark they would no longer see our normal content but a custom '404' page indicating that something was wrong; to make matters worse, removing the bookmark and adding a new one would NOT fix the issue - this was a showstopper for the business (with a fair share of emails emphasizing the gravity of the situation). BTW, the complains started the same week Apple has released iOS 6.1.2 (and this was constant with all of our customers); some of them, using previous versions of iOS had the same issue, but removing the bookmark seemed to fix it. But, as Apple is very pushy with their updates, probably quite a couple of our customers had already updated ... poor them.

After some investigation we figured out that the '404' page belonged to one of the public WiFi providers (namely The Cloud) and after some calls to our customers, the common denominator was that all of them have been connected to The Cloud, they tried the bookmark, got the 404 page and haven't been able to get rid of it not even after connecting to their mobile data connection (or private wifi), which worked previously; YES, you've heard me right, the page was cached and there was nothing they could do, not even removing the bookmark would do any good (although by Apple's standards, the application 'sand-box' should be cleared when removing the bookmark). So my conclusion was that we were hitting a caching issue and after eliminating HTML5 caching features we concluded that it's down to iOS/Safari. To make matters worse the behavior was not consistent, meaning that most of the times the issue would reproduce, but sometines it wouldn't.

Also, while investigating this, we came accross a weird situation in which the same sequence of actions would sometimes cause the 404 page to be displaied while other times it would display The Cloud's login page - I didn't mention it before but the 404 page was shown as a consequence of the wifi router trying to redirect the user to the login page (it's one of those providers that ask you to login before actually offering internet access). This had me thinking about a race condition in Safari - we've had some phones on which we were never able to reproduce the issue, probably because those were a bit slower then our test devices.

The only solution I was able to find was to add something unique (a timestamp/GUID) to the URL every time the application starts; in our case it was pretty easy due to the launcher page that we were using; I've just changed it to inject a GUID with each request and VOILA. The downside is that I don't know what happens with all the sandboxes the bookmarks would generate while removing and adding them again, but Apple must have thought that out :).

Here's a breakdown of the steps to reproduce (I was able to reproduce this with lots of other apps, so it's not really related to how the app was coded or designed):

1. Via mobile data connection (or wifi), bookmark an application that supports standalone mode; open it via the bookmark to see the normal content

2. Connect to The Cloud (without logging in) and open the bookmark - chances are that you'll get the '404' page; if you don't, close it and open it a couple of times until you do

3. Go back to the mobile data connection (or private wifi) and try the bookmark again - you'll get the same '404' page as with step 2. And belive me there's nothing you can do to get rid of it than actually changing the application code (I've proxied the calls to the webserver and once the page is cached, no requests are comming through from the device).

Finally, I've filed a bug report with Apple which they've acknowledged by linking it to a previous report; hopefully they'll fix it soon.

And all of this is to confirm my negative feelings about iPhones,iPads and all Apple related stuff :).

By the way I was able to create a basic page (blank page with some text and relevant standalone app directives) that would reproduce the issue -> case closed.

Here's a link to the SO issue I've opened on this matter, maybe it will help clarify the issue.

No Comments

Add a Comment