Ki

There are several good private browsers on iOS already — Brave, DuckDuckGo Privacy Browser, Firefox Focus, Orion. I built Ki because none of them was exactly the daily-driver I wanted, and because the differentiation between them turned out to matter more than the categorical "is it private" question.

The product Ki is trying to be: a browser you use every day, whose entire ergonomic posture is to do less by default and let you turn things on per site if you want them. Most browsers are the opposite shape — they ship a permissive default and ask you to opt out of cookies, trackers, and identity sync. Ki ships strict defaults and asks you to opt in.

Apple's App Store policy requires every iOS browser to use WebKit as the rendering engine. There is no Gecko on iOS. There is no Blink on iOS. Chrome on iOS is a WebKit browser wearing a Chrome wrapper. Brave on iOS is a WebKit browser wearing a Brave wrapper. Ki is a WebKit browser too. The rendering and JavaScript execution are the same across every browser; the differentiation lives entirely in what each app does around that engine.

Which means "private browser on iOS" is not a single category. It's a set of decisions about:

• Which content rules ship in the WKContentRuleList compiled into the app.
• What permission UI sits in front of the WebKit storage and JavaScript APIs.
• Where bookmarks, history, tabs, and per-site state are stored, and whether anything syncs off-device.
• Whether the app phones home for anything — updates to the block list, telemetry, search-suggestion proxying, anything.

Ki's answers, in order: ships the block list in the app bundle so it updates only when you install a new app version; per-site shield in the URL bar with explicit grant/revoke per origin; bookmarks, history, tabs, and permissions stay on device with no sync to a studio server; the app makes zero network requests to any infrastructure of the studio's.

Most browsers offer a global cookie or script switch. That's the wrong granularity. The web is per-origin — permissions should be too.

Ki's shield lives in the address bar. Tap it on any site and you see exactly which permissions that origin has: cookies, scripts, camera, microphone, location, storage. Toggle any of them; Ki remembers the choice for that origin. The next time you visit the site, you keep the posture you set. There is no global "allow all" toggle you forgot was on.

This is the design call most browsers refuse to make. Per-site UI is more work to render and more work to learn, but it's the only honest model. The web is not one thing. A browser that treats it as one thing — "allow all cookies" / "block all cookies" — is making a usability shortcut that costs the user clarity about what's happening.

Separate browsing contexts on the same device. Research profile. Shopping profile. Personal profile. Each has its own cookies, history, and per-site permissions. Switching is one tap.

The reason this matters: the real cross-site tracking problem isn't that any one site is malicious — it's that signals leak across browsing contexts that should have nothing to do with each other. Your shopping behavior should not be context for your research. Your research should not be context for your personal use. Profiles enforce that boundary at the browser level instead of asking the user to remember to use private browsing every time they want to research a competitor.

Most "reader mode" implementations are visual filters — they hide the chrome and reflow the text but still execute the page's JavaScript. Ki's reader mode disables JavaScript entirely and applies a locked-down Content-Security-Policy in the reader view. You read the article without inheriting the page's surveillance posture.

The mechanics matter: stripping the page visually while still letting the JS run means the trackers and analytics scripts still execute, still phone home, still build a profile of you reading. The reader mode that exists in most browsers is decorative. Ki's reader mode is structural — if you switch to reader, the page genuinely can't do anything except render text and static images.

Long-press the URL bar and tell Ki what to do. "Summarize this page." "Find me the contact email." "What's the studio behind this product?" On iPhones that support Apple Intelligence, the assistant runs entirely on-device via Apple's Foundation Models. The page content never leaves your device.

On devices without Apple Intelligence, the assistant falls through to a bring-your-own-key path. You can attach an OpenAI or Anthropic key in settings; the request goes directly from your phone to the provider, with whatever page context you authorized. The studio runs no proxy and no relay. If you can read the network trace, you can confirm exactly where each request went.

This is the same hybrid posture I used in Captain's Log: on-device first, BYOK second, never proxied through a studio service. The decision is the same one — making AI work in a privacy-first app requires the app to never be the middleman.

Not a Chromium fork — iOS won't allow that. Not a desktop browser. Not a VPN; encrypted transit is between your device and the destination server, same as any browser. Not "private" in the Incognito-tab sense, where private only means "doesn't save to local history but still leaks to your ISP and to every site you visit." Not a crypto wallet, an ad-blocker disguised as a browser, or a personality cult.

The studio is interested in shipping a browser that defaults to leaving you alone, and nothing else.

Building Ki taught me that the hardest design problem in a privacy product is not the policy — it's the defaults. Anyone can write a privacy policy that says the right things. Making the defaults match the policy means rejecting features that are individually appealing because they would broaden the surveillance surface.

The product is more honest because of every feature it doesn't have. No reading list synced to a server. No cross-device tab sync. No accounts. No telemetry. Each one would have been a marketable feature in another product; each one would have been a contradiction here.

The studio's product overview lives at 941apps.com/ki. Ki is currently in TestFlight; email [email protected] for an invite.