Still working on https://exist.io, a platform for quantifying and tracking data about your life. We've been around for about a decade now and seen many competitors come and go — this niche is definitely not at the peak of the hype cycle any more. On the other hand, Apple Watches have normalised tracking body stats like activity (and sleep to a degree), and yet we think there's still so much more that can be done with that data. We're still (always) working on improving our insights and correlations to find better ways to use the data to optimise your health, mood, productivity, and so on. But not with "AI" :)
If you want to do something similar without hosting it yourself, you can try my thing https://exist.io. It has a full API in addition to a bunch of integrations.
Sure, the cookies expire (in two weeks I think, in this case) but that doesn't invalidate the issue that the wkwebview silently shares cookies with nsurlsession, nor does it negate the confusing journey of tracking down the bug. Sheesh.
We do not need to honour cookies when making requests to the API as we use token authentication. Even if we wanted to keep users logged in within the web view, which we don't because the web view is just for static help pages, we wouldn't want to send those to the API.
Then you should disable cookies on your API calls by setting the `httpCookieStorage` property of your URLSessionConfiguration to nil. You could also use an ephemeral configuration (which will preserve cookies set by the API in memory but won't share them with webviews), which may or may not be a good idea depending on if you're using this session for anything that should be cached to disk (e.g. downloading images).
This is the correct answer and the reason that NSURLSession really came into existence - there is a need to partition behaviors between different frameworks and subsystems and the previous NSURLConnection model relied on a smattering of process global configuration options.
I'd be surprised if AFNetworking didn't also offer the ability to create a "private" NSURLSession with custom storage objects.
I'd also recommend looking into debugging these types of issues using, eg, Charles Proxy. There's more information on logging at:
I think it is fair to say that the users don't really care as long as the implementation is done well, but if information about me is worth storing in a cookie (login information, perhaps), it is probably worth sending on all requests, even outside of the browser. If I've already logged in via the web browser, I don't want to have to login again to use your API (and vice versa). It seems like a sensible default. The server can always ignore the cookies if they are not needed.
