Back in iOS 8, Apple introduced a new control for hosting web content:
In most respects, it’s far superior to the old
However, one area in which
WKWebView is demonstrably worse is in its handling of cookies.
iOS provides a service called
NSHTTPCookieStorage that is used by most HTTP-related functionality, including
The reason for this is documented in a long-lived webkit bug.
WKWebView, most of the underlying functionality actually lives in a process outside of your application.
Unfortunately, this complicates interactions with things that do live in your application—like cookie stores.
While this issue has been addressed on master, it’s not yet in a shipping version of iOS. (it looks like iOS 11 may provide a way to interact with
WKWebView’s cookie store)
For apps that host web applications that depend on cookies for authentication, this poses a major problem. Although web requests originating in the application can access the shared cookie store, these cookies are never propagated to the web view, meaning that subsequent AJAX requests or page navigations will be unauthenticated.
If you have control of the server hosting your web content, there’s another way to slip your cookies into a
just get the server to send back a
Set-Cookie header in its response to your initial navigation request.
In the case of an app that I was recently working on, we added a small bit of code on the server looking for an
X-Echo-Cookie HTTP header.
For any request containing this header, it would include a
Set-Cookie header whose content was whatever was in the request’s
By including this header on our initial navigation request, we were able to get the cookie to “jump” from the application’s cookie store to
While this solution doesn’t cover complex scenarios, like the cookie being updated or invalidated while the user is navigating, it worked just fine for our scenario.