ONIX iOS Client¶
No canonical source reference exists for ONIX iOS
At the time this documentation set was built, the iOS repository this review inspected has no ONIX-owned remote and no canonical branch. Its only configured remote is a local, push-disabled fetch path to an older, differently-branded multi-platform codebase. Two local commits — described below as Candidate A and Candidate B — could each plausibly be read as "the current iOS source," and nothing in the repository states which one, if either, is the one that ships. This page does not resolve that question and does not claim that either candidate ships; it documents both candidates and bounds every capability claim to the candidate it was actually read from.
The uncertainty, in full¶
- The repository has exactly one configured remote, pointing at a local filesystem path
outside this review's scope, with push explicitly disabled on it. It has no
originand no remote that resolves to an ONIX-owned host. - Candidate A — commit
9ce6595cebe8c77660f02a00be5c7a97ddcd72e1, treebdc3f2c66be72957043d58037474f02a65b2e668. Marketing version0.1.0, build1. This is the commit an earlier "A0" scoping lane in this repository's own history treats as its starting baseline. - Candidate B — commit
85cbdf09499ed3f5c3c37fb6ace34f8926e741f5, treefa9f9699254873bd4b72d4eab047ce43e0be5c2f. Marketing version0.1.1, build3. This commit is later in the same line of local history as Candidate A and adds capabilities Candidate A does not have (see below). Its most recent ancestor commits include one titled "Prepare ONIX iOS shell for TestFlight," which is the basis for describing this candidate as TestFlight-stage — not for describing it as shipping. - Neither candidate has been pushed to, or reviewed against, any remote this documentation set could treat as authoritative. Promoting either one to "the" canonical iOS source is an owner decision this page deliberately does not make.
The full record of remotes, refs, and exactly how each candidate was read is kept in this documentation set's internal evidence record and is available to maintainers on request; it is summarized here only to the extent needed to bound the capability claims below.
What is verified, and from which candidate¶
Everything below is true of the specific candidate cited. Where the two candidates agree, that is noted; where they differ, both are shown.
Shell architecture (both candidates)¶
The iOS app is a single, constrained WKWebView pointed at a configured ONIX frontend origin — not a native reimplementation of any ONIX screen. A pure, dependency-free navigation policy function decides what to do with every attempted navigation:
- The WebView's own empty document, and same-origin
blob:child frames the loaded page creates (needed by the charting widget), are allowed. - Any other non-http(s) scheme —
javascript:,data:,file:, a custom scheme — is refused outright: never loaded, never handed to another app. - An http(s) destination whose origin exactly matches the configured ONIX origin is allowed inside the app.
- Any other http(s) destination is handed to the system browser, never loaded inside the app's own WebView.
- If no ONIX origin is configured, every case fails closed to a refusal rather than guessing a destination.
This decision is made by comparing whole, canonicalized origins — not by substring or prefix matching on a hostname — specifically to avoid a policy that would wrongly admit a look-alike host.
No local MCP server, no native trading surfaces (both candidates)¶
The iOS client has no MCP server and no automation surface of any kind; that capability is macOS-only. Native Swift code never calls the ONIX backend, an exchange, or a broker directly — every data request the loaded page makes goes through that page's own same-origin API routes, entirely inside the WebView. Native, write-capable or account-state-revealing surfaces (a positions view, trade execution, trade review) are explicitly out of scope for this client rather than present-but-disabled: if a screen like that exists at all, it exists only inside the web page the WebView loads, under whatever access control that page enforces when an authenticated ONIX session is present.
Authentication is fail-closed, and identity is currently incomplete (Candidate A)¶
Candidate A's Release build ships with no accepted ONIX identity contract. Its auth-state abstraction never reports a signed-in state on its own; a native "session" is display-only metadata (a label and a start time), never a token, cookie, or credential — those, if they exist anywhere, live inside the WebView's own same-origin storage, which native code never reads. A DEBUG-only synthetic developer session exists purely so the shell has something to display while under active development; it is compiled out of Release builds and is explicitly labeled as not a real ONIX identity.
This means multi-user identity should not be assumed complete for this client at Candidate A. See Support Boundary.
A later candidate adds a biometric privacy gate that is not account authentication (Candidate B)¶
Candidate B adds a Face ID / Touch ID gate that can lock and unlock the app shell. Its own source documentation is explicit that this is not an authentication implementation: it never sees or stores a username, password, token, or cookie, and it can be dismissed by the device-owner passcode fallback or by explicitly declining biometrics — none of those choices authenticate an ONIX account. Sign-in, when it happens, remains the responsibility of the web page loaded inside the persistent, same-origin WebView, if and when that page has an authenticated ONIX session.
Distribution¶
Both candidates describe themselves as pre-release. Candidate B's local history includes a commit titled "Prepare ONIX iOS shell for TestFlight," consistent with an invite-only TestFlight distribution rather than a public App Store listing. Do not describe ONIX iOS as publicly available, or as shipping. No App Store listing evidence was observed for either candidate, or for this repository's remotes, and none should be inferred. See Support Boundary for the exact language this documentation set uses about availability.
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:
ios-candidate@9ce6595c:docs/PLATFORM-MATRIX.md (blob 4caf73b6a2279abfe5fd78ea121b2026a55b1aab)ios-candidate@9ce6595c:ONIX_iOS/OnixEndpoint.swift (blob e5e3f034744581055b27c1601605b7cc0fc7868d)ios-candidate@9ce6595c:ONIX_iOS/OnixAuth.swift (blob 9389d2e50d08c5a4e8261c98bb0c8accd0190971)ios-candidate@85cbdf09:ONIX_iOS/OnixBiometricLock.swift (blob 7f92e18f317ab3141d7cda0a64740d022ed73a1c)
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.