Ios7 Safari: Saving to Home-Screen and Persist Token

iOS7 Safari: Saving to Home-screen and persist token

Since iOS 5 Apple have been making Home Screen bookmarks more and more isolated in terms of sharing data between the Safari browser and what is now considered a sandbox application.

• iOS <= 5:Everything was cool, local storage, cookies, the works was shared between Home Screen and the web page. Transition between the site and Home Screen was seamless and web developers were happy.
• iOS 6: Apple started treating Home Screen apps (including ones saved from the web) as sandboxed applications. Essentially the Home Screen app that displayed your saved site became a WebView control and was not embedding Safari itself. This prevented local storage from being transferred, but you could still share cookies.
• iOS <= 6.x: Cookies became somewhat unreliable after a certain dot release, they were still shared, but did not get transferred on first save. If you went back to the site, and performed some action, the cookie would magically become available to the Home Screen app.
• iOS 7: All forms of data sharing (local storage, cookies etc.) between Home Screen and the site from which it was saved have been lost (almost), crushing developer's dreams the world over.

At the time of writing (iOS 7.1 in beta), you have only one option.

1. When your page loads, add your token/data to a query string parameter in the URL using JavaScript (window.location.search). When the user saves the site to their Home Screen, the URL is used as the key. Your JavaScript can easily extract the query string parameter you sneaked in earlier if you detect that you are in Home Screen mode (window.standalone). This should work forever, except the value in the URL will also be there forever.

2. Another trick that is to 'render' any value you want to carry across to the Home Screen in the DOM. Since the early versions of iOS, the HTML that is rendered at the time it is saved to Home Screen, will remain unchanged. When launching a Home Screen web app, it does not request the content from the URL. It simply loads the HTML that was previously saved with no initial web request (all links to CSS and JS in the HTML will be requested, but not the page itself). With the knowledge that the HTML is forever saved, so will anything you rendered in it as well. The only way to update your page is to do a windows.reload or equivalent redirect if you aren't pulling your content via AJAX. Long story short, inject your value into a hidden input field for example and it will be transferred across.

Option #1 is will probably last forever, it's not likely the Home Screen will ever alter the URL in any way. Just make sure you have some JS in place to flip a switch and reload the page if you ever want to get rid of it.

Option #2 is somewhat risky because one day the all knowing Apple could decide that a initial page request should actually be made instead of using the same HTML at the point it was saved. This would then wipe out the data you have and the current state of any elements in the DOM.

UPDATE: The DOM injection technique is no longer valid either (iOS 7+), only the DOM directly downloaded from the server is saved to Home Screen. Any dynamic changes made during runtime are lost. Struck out option #2 since the question is for iOS 7 and it longer works, which leaves you with only option #1, adding something to the URL which will always get saved to Home Screen.

iOS11 Safari: Add to Home-screen localstorage lifecycle

Local storage is not cache, it is persistent storage. You can add or delete values manually.

Apple's documentation says the following:

Safari supports the latest HTML5 offline data storage features. Your
application can store its information on the local machine using
either a simple key/value-based data store, or a robust SQL database.
The data is stored locally and persists across launches of Safari so
your application doesn’t need a network connection to access the data,
improving startup time and overall performance.

This storage is limited to 5 MB and can be cleared if the device is running low on space, but this is the main way to store data on the user's device.

You can learn more about local storage here

Cookie not saving in safari when adding to home screen

In the end i solved it using localStorage in ios instead of cookie, if someone is to answer the question correctly i'll mark his as the right answer.

How to maintain login status in a PWA initially loaded via Safari 14/iOS 14?

It can be done. Here's how we've succeeded in doing it:

1. When the user initially logs in to the app in the browser, we generate a UID on the server.
2. We pair this UID with the username in a server file (access.data).
3. We generate the web app manifest dynamically. In it we set the start_url to the index page and append a query string incorporating the UID e.g. "start_url": "/<appname>/index.html?accessID=<UID>".
4. We create a cookie to verify that the app has been accessed e.g. access=granted.
5. When the user accesses the app as an iOS PWA, the app looks for this cookie and doesn't find it (cunning ;) - we use one of the iOS deficiencies (not sharing cookies between Safari and the PWA) to defeat that same deficiency).
6. The absence of the access cookie tells the app to extract the UID from the query string.
7. It sends the UID back to the server, which looks for a match in access.data.
8. If the server finds a match, it tells the app that the PWA user is already logged in and there's no need to again display the login screen. Mission accomplished!

Note: Android/Chrome simply ignores the accessID in the query string - I was wrong in my question to imply that Android/Chrome requires an unmodified start_url.

---

Related Topics