Why you can't build this with iframes

1. Most useful sites refuse to be framed

Two response headers control whether a document may be loaded inside a frame, and either one is enough to stop you.

• X-Frame-Options: DENY or SAMEORIGIN — the older mechanism. The browser refuses to render the document in a frame belonging to another origin.
• Content-Security-Policy: frame-ancestors … — the current mechanism, which supersedes X-Frame-Options where both are present. It names exactly which origins may embed the page; anything else is blocked.

Neither is exotic. Sending one of them is standard practice for defending against clickjacking, which means it is close to universal on exactly the categories you would want on a dashboard: trading and brokerage platforms, banks, admin consoles, internal tools, social networks. The failure is not subtle either — you get an empty rectangle and a console message, which is usually the point at which people go looking for a different approach.

2. Your login doesn't come with you

Suppose a site does allow framing. It is still a cross-site context, and cookies behave differently there.

Session cookies are overwhelmingly set with SameSite=Lax — which is also the default browsers apply when the attribute is absent — and a Lax cookie is not sent on cross-site subresource requests, which is what an iframe load is. Cookies explicitly marked SameSite=None; Secure can travel, but those are exactly the third-party cookies that browser privacy work has spent years restricting: Safari's tracking prevention blocks them outright, and the Storage Access API only helps when the embedded site asks for access and the user grants it per-site, after a gesture.

The practical result is that your framed dashboard shows you a login wall, or an anonymous version of the page, rather than your account.

3. Even when it works, you get the whole page

An iframe embeds a document, not a region of one. You can size the frame down and set overflow: hidden, but you cannot reach inside a cross-origin document to scroll it to the right place or hide the parts you don't want — the same-origin policy blocks the DOM access and the injected CSS that would take. So you are back to a small window onto the top-left corner of a page whose interesting part is somewhere else.

What a native web view does differently

SplitWeb doesn't frame anything. Each pane holds its own WKWebView — the same WebKit engine Safari uses — and loads the page as a normal top-level document. That changes the situation at each of the three points above:

• No framing context exists, so X-Frame-Options and frame-ancestors simply don't apply. They govern embedding, and there is no embedding here.
• The page is first-party in its own view. Panes share a persistent website data store keyed to the app, so cookies and logins survive quitting and reopening, the same way they do in a browser.
• Cropping happens at the view layer, not the DOM layer. The web view is rendered at the size it had when you drew the selection and then scaled and offset so that the selected region fills the pane. Nothing is injected into the page, so there is no same-origin problem and nothing to repair when the site redesigns.

There is a cost, and it is the mirror image of the benefit: a real web view per pane is far heavier than an iframe. That is what keeps a page from reloading when you rearrange the board, and it is also why memory use climbs as you add panes. And while a crop is applied the pane is read-only — clicks pass through it, so you turn the crop off when you need to interact. How cropping works in detail.