← All posts

An in-app browser is not a smaller Safari

· 7 min read

A clay-style shopping cart

Because the app never handed the link to iOS. It opened the page itself, in a browser it builds into the app, and that browser is not Safari wearing a different toolbar. It keeps its own cookies. Which is why a store you are permanently logged into asks you to sign in again, and why the card you have saved is nowhere.

That one distinction explains almost everything odd about buying something from a feed on an iPhone.

A real browser, in a window the app owns

Apple gives developers a component called a web view. Drop it into an app and you get WebKit, the same engine underneath Safari, rendering any page you point it at. TikTok, Instagram, Pinterest, Reddit and most of the apps you shop from use one to display links, because keeping you inside the app is worth a great deal to them and a tap out is a tap they may not get back.

So the engine arrived. The browser did not. Everything Safari keeps around the engine stayed behind: your cookies, your history, your extensions, your saved logins in the form you are used to.

The address bar tells you where you are, if you look. In there it is usually a short read-only strip showing a domain or a page title, which you cannot edit and often cannot read in full. So checking a URL before you trust it gets harder in exactly the place where the link came from a stranger. The full version of that check is worth knowing by heart for this reason.

Why you are logged out of a shop you use weekly

A login is a cookie. Safari keeps its cookies. An app's web view keeps its own, in storage that belongs to that app, and iOS does not let the two see each other. This has been the behaviour since iOS 11, and it holds between apps too: a store you signed into inside TikTok is still signed out inside Instagram.

The consequence nobody expects is the bookkeeping. You end up maintaining several half-logged-in copies of the same shop. One in Safari with your address and your order history. One inside TikTok, created the evening you gave up and signed in again. Next month you are guessing which of them placed the order you are trying to return.

The checkout failures, roughly in the order they bite

Leave before you add to cart, not after

This is the habit worth changing, and it is the reverse of what people do.

A cart is a session, and the session lives in whichever browser you built it in. Fill a cart inside TikTok's browser, hit a wall at payment, then tap Open in Safari. Safari loads that URL with no idea who you are. Empty cart, no saved address, and the whole thing done twice.

So decide early rather than at the payment screen. Browsing, checking a price, working out whether the thing is even the thing: stay in the app, it is faster and back is one tap. The moment you intend to buy, get out first, then shop.

How to get the page into the real browser

One thing that is not the fix: choosing a different default browser in iOS Settings. That decides which browser receives a link once the app has decided to hand one over. It does not stop the app reaching for its own web view first.

The mirror-image confusion has the same root. When a tiktok.com address opens the TikTok app instead of a web page, it is because the app holding that link asked iOS to check whether an installed app claims it, and one does. Whether that check happens at all is up to the app you tapped from, which is why the same address behaves one way in Messages, another way in Notes, and a third way inside a feed.

The keystroke story, stated fairly

In August 2022 the researcher Felix Krause published a tool that reveals what JavaScript an app injects into pages loaded in its own browser. He reported that TikTok's iOS app injected code subscribing to every keyboard input and every tap on pages opened in its in-app browser. He was careful about what that proves: code being present is not evidence that keystrokes were recorded or sent anywhere, and from outside the app there is no way to tell. TikTok disputed the keylogging framing and said the function was used for debugging and performance monitoring.

Read it as a reason to be deliberate, not alarmed. Injecting script into a page is not a trick, it is what the component is for, and it is how an app fits a page inside its own interface. But typing a card number into a window another company controls the inside of is a choice you can avoid for free, in two taps.

Where the in-app browser is the right place to be

Most of the time, honestly. It is quicker, it holds your place in the feed, and returning is one tap instead of an app switch. For reading a product page or checking a price against the one the creator claimed, that beats the cookie question outright.

And on TikTok Shop specifically, the checkout is not a web page at all. It runs natively inside the app, which is why paying for a product tagged in a video feels different from paying on a brand's own site reached through the same feed. Everything above is about the second case: someone else's shop, opened somewhere it was not expecting to be.

The general version of what does and does not travel between apps on an iPhone is in what an app actually gets when you tap Share. The short form: an address, not the contents of the house.

Getting to the right page in the first place

None of this helps if the link in the bio is the wrong product, or there is no link at all. That is the part Stealsy does: share the video from TikTok or Instagram to the app, and it comes back with the products in it, priced, each with a shop link our servers opened and checked before you saw it, plus cheaper dupes when they exist.

The limits out loud: iPhone only, iOS 18 or later, and it does not change how anyone's in-app browser behaves. You still open the page yourself, and you still want to be in Safari when you pay. What it changes is that the page you open is the right one.

Get Stealsy for iPhone — share a video, get the products, prices and verified links.

Common questions

Why does a shop link open inside the TikTok app instead of Safari?
Because the app never handed the link to iOS. Apps can embed a web view, which is a component that renders web pages using WebKit, the same engine underneath Safari, inside a window the app controls. TikTok, Instagram, Pinterest and most feed apps show links that way, because a tap out of the app is a tap they may not get back. The page you see is rendered by the same engine as Safari, but it does not inherit anything Safari keeps around that engine: your cookies, your logins, your history, or your extensions. That is why it looks like your browser and behaves like a stranger's.
Why am I logged out of a store in TikTok's browser when I am logged in on Safari?
A login is a cookie, and cookies are not shared between Safari and an app's in-app browser. Each app's web view keeps its own cookie storage, and iOS does not let the two read each other. That has been the behaviour since iOS 11, and it applies between apps as well, so a store you signed into inside TikTok is still signed out inside Instagram. Nothing is broken and there is no setting to merge them. Signing in again inside the app works, and it creates a second half-logged-in copy of that store rather than repairing the first.
How do I open a link from TikTok or Instagram in Safari on my iPhone?
Tap the three dots in the corner of the in-app browser and choose the item that opens the page outside the app. Depending on the app and version it reads Open in browser, Open in Safari, or Open in default browser. If no such item exists, copy the link from that same menu and paste it into Safari yourself. There is no iOS setting and no setting inside TikTok or Instagram that sends every link out automatically. Choosing a different default browser in iOS Settings does not help, because that only decides which browser receives a link once the app has already decided to hand one over.
Should I enter card details in an in-app browser?
You can, and it is usually uneventful, but there is no upside to doing it there. The company whose app you are in runs the window the page sits in and can inject JavaScript into that page, which is what the component is designed to do rather than a trick. Meanwhile the fastest and safest payment paths tend to be missing in there: Apple Pay on the web is built for Safari and often absent, Sign in with Google is blocked outright in embedded web views, and passkey prompts frequently fail to appear. Opening the same page in Safari costs two taps and gets all of that back.