Native Clients Overview¶
ONIX's macOS client ships as a native application shell alongside the web product. A separate iOS client exists, at the time of writing, only as two local, non-canonical source candidates — see "Source status differs sharply between the two clients" below — and nothing on this page or elsewhere in this documentation set should be read as a claim that an iOS client ships or is generally available. Where either client exists, it is a thin native wrapper around the same ONIX frontend that the browser loads: neither ships its own chart engine, its own market-data pipeline, or its own trading logic. The web product (documented under Product) remains the single source of truth for what ONIX shows and does; the native clients exist to host that product inside a native window or WebView and, on macOS only, to expose a small set of local automation tools.
This page orients the two clients at a high level. See ONIX macOS Client and ONIX iOS Client for the verified specifics of each, and Support Boundary for what is and is not supported.
What each client is¶
ONIX macOS is a native SwiftUI application that hosts a WKWebView pointed at a configured ONIX frontend origin, plus a companion local MCP (Model Context Protocol) server that lets an AI coding client — Claude Code, Claude Desktop, Cursor, or similar — drive the running app through a small, typed tool surface. The macOS app owns window management, navigation, diagnostics, and this local automation transport; it does not own market data, the chart, the datafeed, a strategy engine, or a broker connection. Those all come from the frontend the WebView loads.
ONIX iOS, at the two local source candidates this documentation set inspected, is a native SwiftUI application that hosts a single, constrained WKWebView pointed at a configured ONIX frontend origin. It has no local MCP server and no automation surface. Its native code is deliberately minimal: an origin-validating navigation policy, an endpoint-configuration screen, and (in the later of the two candidates) an optional biometric privacy gate that locks and unlocks the shell without performing account authentication. Everything a user does inside the app — signing in, viewing a chart, reading data — happens inside that single web surface, exactly as it would in a browser tab pointed at the same origin, when an authenticated ONIX session is loaded there.
Neither client talks to the ONIX backend or to any exchange directly from native code. Every data request the loaded page makes goes through that page's own same-origin API routes, inside the WebView, the same path the web product itself uses.
Distribution reality¶
The macOS client is private, test-stage software: no App Store listing was found for it, it has no public download page, and it should not be described as generally available. The iOS candidates are source-only and unreconciled — see below — so this page makes no distribution claim about iOS beyond noting that one local candidate's commit history references preparing a TestFlight build. Where a build has been prepared for TestFlight, that means an internal or invite-only distribution channel, never a public release. See Support Boundary for the exact language to use when describing availability, and the source-specific pages for what is verified about each client at the pins this documentation set was built from.
Source status differs sharply between the two clients¶
The two clients are documented very differently on purpose, because their source situations are not equivalent:
- macOS has a canonical repository, a canonical remote (
onixlab-ai/onix-macoson GitHub), and a specific reviewed commit with a verified marketing version and build number. See ONIX macOS Client. - iOS does not currently have a canonical repository reference. The repository this documentation set inspected has no ONIX-owned remote — only a local, push-disabled fetch path to an older, unrelated multi-platform codebase — and two different local commits could each be read as "the current iOS source," with no recorded decision about which one is authoritative. This is a publication blocker, not a cosmetic gap: no page in this documentation set asserts that either candidate is the client ONIX ships. ONIX iOS Client documents both candidates and states this uncertainty plainly rather than picking one.
Relationship to MCP¶
The macOS client's local automation surface is one of two MCP surfaces in the ONIX product; the other lives in the backend, as a separate, local, stdio-only process, not a network service. See MCP in ONIX for how the two differ in trust and scope, and The macOS MCP Host for what the local host exposes and how it is secured.
Evidence and source pins for this page
Unverified. Could not be confirmed against the pinned sources. Treat as an open question.
Verified on against the following immutable sources:
macos@984bdf6c:MCPServer.swift (blob 05f763c1976410fbab50937a3c3c0fdd1583727e)macos@984bdf6c:MCPSecurityTests/Package.swift (blob 58ea4c702e76fc0059610d6392fb2db56fc1414a)ios-candidate@9ce6595c:docs/PLATFORM-MATRIX.md (blob 4caf73b6a2279abfe5fd78ea121b2026a55b1aab)
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.