Why your mobile app keeps forgetting who the customer is

A client came to us with a mobile app where the shopping cart seemed to have a memory problem. Add an item, back out to browse, come back, and sometimes the cart was empty again. Nothing in the server logs looked wrong, every request was handled correctly. The bug wasn't in the cart logic at all. It was in an assumption nobody had questioned: that the app could identify a returning visitor the same way a website does.

The assumption that breaks

On a website, a guest's cart is tracked with a cookie the browser stores and quietly resends on every request. Login state, "remember me", email verification, all of it usually rides the same mechanism. It's so automatic that most web teams never have to think about it directly.

Native mobile apps don't get that for free. fetch on a phone has no shared cookie jar the way a browser does, so if a backend was built cookie-first and a mobile client just calls the same endpoints, every request looks like a brand new anonymous visitor. Anything the server was relying on a cookie to remember, cart contents, verified status, session state, gets silently dropped between screens.

The fix: carry identity in the payload, not the transport

The reliable fix is to stop depending on the transport layer to remember anything and hand the identifier to the client explicitly instead:

• Accept an identifying token as a request header (something like X-Session-Token), falling back to the cookie so the existing website keeps working untouched.

• Have the server echo the resolved token back on every response, so the client always knows exactly what to send next time, even the first time, when it didn't have one yet.

• Store that token on-device (secure storage, not just memory) and attach it to every request that touches session-dependent data.

Nothing about this is exotic, it's the same pattern APIs used long before browsers had cookies. It just has to be done deliberately, because a mobile client will never get it by accident the way a browser does.

Why this is worth knowing before you build

This isn't a mobile-specific quirk, it's a symptom of a more general problem: backends built API-first for one client (usually a browser) tend to bake in assumptions about that client's capabilities. Cookies are the most common one, but the same trap shows up with things like redirect-based auth flows or same-origin file uploads. The earlier a team designs the identity layer to be transport-agnostic, headers and tokens rather than anything the browser does automatically, the less rework is needed when a second client (mobile, a partner integration, a CLI) shows up later.

If you're planning a mobile app on top of an existing web backend and want someone to check the API for assumptions like this before they turn into bug reports, talk to us.