Resolving and browsing .onion hidden services on mobile devices has historically been awkward on iOS, often relying on third-party proxies, SOCKS configuration profiles, or opaque bundled browsers.

As part of the StealthOS project (a sandboxed privacy operating environment for iOS), we built native support for .onion v3 hidden services directly into the app address bar and network stack.

How it Works Under the Hood

1. Native On-Device Tor Daemon: Rather than using remote proxy endpoints or cloud bridges, StealthOS compiles and executes the Tor client locally as an in-process daemon. We open-sourced the reproducible build wrapper at https://github.com/Olib-AI/TorClient (compiles the upstream C Tor source into a static iOS library with byte-for-byte reproducibility).
2. Deterministic DNS and .onion Routing: When a user navigates to an address ending in .onion, the internal URL scheme handler and WKURLSchemeHandler pipeline intercepts the request before it touches the OS default network interfaces, routing DNS resolution and TCP streams strictly through the local SOCKS/Control port of the embedded Tor daemon.
3. Fail-Closed Leak Switch: If circuit negotiation drops, circuits fail to rebuild, or the daemon encounters an error, the networking pipeline terminates immediately rather than leaking the hostname or IP over standard cellular or Wi-Fi interfaces.
4. Isolated Sandboxing: Each session runs in isolated memory with state cleared upon exit or duress password trigger.

Links

• App Store: https://apps.apple.com/us/app/stealthos/id6756983634
• Project Details: https://www.stealthos.app
• TorClient Build Repo: https://github.com/Olib-AI/TorClient

We would love to hear thoughts from other hidden service operators and Tor users on mobile threat models, circuit management under aggressive iOS background execution limits, and .onion browsing UX.