iOS SwiftExampleApp — TEST_PLAN QA run status & blockers

[QuantumExplorer]

Living tracker for QA runs of the iOS SwiftExampleApp against packages/swift-sdk/SwiftExampleApp/TEST_PLAN.md, driven on the booted iOS simulator (via idb, the simulator-control skill). Updated per build. Distinguishes real pass/fail from environment/tooling blockers.

Environment: testnet · fresh v3.1-dev build · iPhone 17 simulator · fully-provisioned wallet (4 identities, Core/Platform/shielded balances).

---

Essential tier — ✅ all passing

All Essential-tier tests pass:

• Core wallet: create / restore / backup phrase / receive / send Core L1 / view balance+tx / SPV sync.
• Identity: create (Core-funded), load/discover, view, identity→identity credit transfer (production UI added in feat(swift-example-app): add identity→identity Transfer Credits production UI #3891).
• DPNS: register, check availability, resolve, get usernames.
• Shielded: sync, view activity, shield from Platform & Core, shielded→shielded transfer, unshield.

CORE-08 (QR scan) is classified Manual (needs a physical camera — not automatable in the simulator), so it sits in its own tier rather than Essential.

Shielded (cross-cutting) — ✅ passing

SH-01 sync · SH-02 view · SH-03 shield-from-Platform · SH-04/SH-07 shield-from-Core (asset lock) · SH-05 shielded transfer · SH-06 unshield · SH-08 withdraw→Core · SH-09 prover · SH-13 receive address — all driven green.
An earlier "no available addresses" failure was diagnosed as an address-list seeding/timing race, not a defect (the shielded path shares the main SDK; it works once the masternode/evonode list is seeded). See #3890.

Common tier — 24 / 32 driven

ID	Action	Result
CORE-09	Multiple HD accounts	✅
CORE-10	Multi-recipient Core send	✅ UI added (Send → "Add recipient"); 2-output testnet send verified
ID-05	Top up (asset lock)	✅ picker fix — driven end-to-end (topped up idx0 from Platform Payment #0; balance increased)
ID-06	Top up (from platform addrs)	✅ picker fix (TopUpIdentityView funds from Platform Payment account addresses — same flow as ID-05)
ID-07	Add public key	✅
ID-08	Create identity (from platform addrs)	✅ picker fix — CreateIdentityView source-wallet + funding-source pickers drivable to submit-ready
ID-09	Set local alias	✅ driven end-to-end — toolbar "Add Alias"/"Save" are absent from describe-all but reachable via describe-point; alias set + persisted to SwiftData
ID-10	Withdraw credits → L1	✅ production UI added + driven end-to-end. New Withdraw Credits button in IdentityDetailView (next to Transfer Credits), sheet WithdrawCreditsView → wallet.withdrawCredits → platform_wallet_withdraw_credits_with_signer (keychain-signed, mirrors ID-04/#3891). Withdrew 0.001 DASH from a funded identity to an L1 address (run on devnet/paloma): "Withdrawal submitted" success screen, identity credit balance dropped 0.09659655 → 0.09331446 DASH (amount + withdrawal fee) and the detail view reflected it via @Query. L1 payout is pooled/async — no immediate txid, and the UI says so (no fake txid). Prereq: withdrawal signing needs a TRANSFER/CRITICAL key; the funded test identity lacked one (predates the keyId-3 derive fix) and failed first with a clean "no withdrawal public key" error and no balance change — a TRANSFER key was added via ID-07 first, then the withdrawal succeeded.
ID-11	Transfer credits → platform addrs	▶ reachable — AddressQueriesView debug form (NOT a picker); the catalog nav-link is drivable (see below), then needs typed identity/address/key input
ADDR-01	Query address info	✅ driven — Queries → Addresses → Get Address Info; returned balance/nonce/found for a bech32m address
ADDR-06	Show platform receive address	✅
DPNS-05	Register contested/premium name	✅
DPNS-06	Select main name	✅
DPNS-07	Search by prefix	✅ driven — Queries → DPNS → DPNS Search, prefix "qa" → returned qa-gauss-0614.dash (+ recordsIdentityId)
DC-01	Load contract from network	✅ driven — Contracts → + ("Add Contract or Token", toolbar PopUpButton via describe-point) → Load Contract → examples list → Withdrawals (4fJLR2GYTPFdomuTVvNy3VRrvWgvkKPzqehEBpNf2nk6, not previously loaded). Sheet dismissed with no error. SwiftData ZPERSISTENTDATACONTRACT went 1 → 2; new row id (hex) 3662BB61…2FE2D97F = the requested id, 2475-byte serialization, linked withdrawal doc type, ZLASTACCESSEDAT = tap time. Free network read, no funds/ST.
DC-02	View contract	✅
DC-03	Create data contract	💸 funds (retry on funded identity)
DOC-01	Query documents	✅ driven — Queries → Documents → Get Documents (DPNS contract GWRSAV…S31Ec / type domain) → total_count: 100 documents
DOC-02	Create document	✅ production UI added + driven end-to-end. Contracts → contract → document type → New Document (schema-driven CreateDocumentView) → platform_wallet_create_document_with_signer (routes through rs-platform-wallet IdentityWallet::create_document_with_signer → SDK put_to_platform_and_wait_for_response, signed by the wallet's keychain signer — not the test-signer builder). Created a preorder doc (saltedDomainHash) on DPNS GWRSAV…S31Ec from funded idx1: network-confirmed, doc id 7i1hJgvVt8fJms26kGwkEZ6jVZxrfd3BrqfmAfpqXMoG, ZPERSISTENTDOCUMENT 0→1, appears in documents list. Also fixed a nav-stability bug that was auto-dismissing the create form (background-sync @Query re-render of the contracts list tore down the contract-details navigation).
TOK-01	View token balances/search	✅ (empty = valid)
TOK-02	Transfer token	💸 needs token fixture
TOK-03	Direct purchase token	💸 needs token fixture
TOK-04	Token queries	💸 reachable — Queries → Token query forms load + execute; "Get Identity Token Balances" requires a Token ID and the wallet holds no tokens → needs a token fixture (same as TOK-02/03). Tooling unblocked.
SH-07	Shield from asset lock	✅
SH-08	Shielded withdraw → Core L1	✅
SH-09	Prover warm-up	✅
SH-13	Show shielded receive address	✅
DP-01	Send contact request	⛔ parked (DashPay, out of scope)
DP-02	Accept contact request	⛔ parked
DP-03	Send DashPay payment	⛔ parked
DP-04	Create/update profile	✅
DP-05	View profile/contacts	✅

Legend: ✅ pass · ⛔ blocked · 💸 funds/fixture · ⚙️ idb-automation limit · 🔌 no UI · ▶ feasible, not yet driven

---

Blockers / follow-ups

• Funds / fixture (retryable): DC-03, TOK-02, TOK-03 — failed only because the test identity (idx0) was drained mid-run; re-run on a funded identity (idx1). (DOC-02 now ✅ — driven on funded idx1; see its row.)
• SwiftUI Picker popovers invisible to idb — RESOLVED. A Picker rendered as a menu popover surfaced only "Dismiss context menu" to idb; its option rows were unreachable. Fixed on branch claude/cool-brattain-b8207a via a shared AccessiblePicker.swift helper: .navigationLink style for Form pickers, .inline for non-Form pickers, plus stable per-row accessibilityIdentifiers. The funding-source, source-wallet, denomination, recipient-identity, and transition (token-register / builder) pickers now expose their option rows. Verified on-device: ID-05 driven end-to-end; ID-06/08 drivable. (Note: Menu { Button } navigation menus like the Identities "+" were never affected — they already exposed their children. And .inline rows are addressable by AXLabel, not a per-row id — a SwiftUI inline-rendering limitation.)
• Catalog NavigationLink "won't push via synthetic tap" — DIAGNOSED, drivable (technique, no code). Root cause: the TOP row of the Settings → Queries / State Transitions catalogs has its accessibility frame overlapped by the large nav title, so a tap at the row's reported center lands on the Heading, not the row (confirmed with describe-point). Fix: tap the row's LOWER edge (or scroll it clear of the title) — verified pushing both the Queries and State Transitions catalogs. Unblocks ADDR-01, DPNS-07, TOK-04, DOC-01, ID-11, and the ID-10 builder nav.
• ID-09 "Add Alias" toolbar button — drivable (technique, no code). Toolbar buttons are absent from describe-all but reachable via describe-point at the nav-bar frame; driven end-to-end (alias set + persisted to SwiftData).
• Remaining are idb-technique gaps, not product bugs. Now documented in the simulator-control skill / memory: use describe-point for toolbar/nav buttons, and tap catalog rows clear of the nav-title overlap. ID-11 still needs a full driven pass (typed debug-form input). (ID-10 driven green — see its row.)
  • → need manual runs or a UI-automation improvement.
• DashPay (DP-01/02/03) — PARKED / out of scope for now. (For reference: sending a contact request fails "External signable wallet has no private key" — receiving-xpub derived in-process; would need the external-signable derivation path.)

Tiers still to run

Thorough (35) · Uncommon (25) · Manual (1: CORE-08, physical device).

Related PRs

#3887 (test plan) · #3888 (multi-wallet) · #3890 (ban-reason FFI + shielded diagnosis) · #3891 (credit-transfer UI) · #3895 (Manual tier) · credit-withdrawal production UI (ID-10, branch claude/festive-thompson-8cc2be) · document-create production UI (DOC-02: platform_wallet_create_document_with_signer + schema-driven CreateDocumentView + contract-details nav-stability fix, branch claude/peaceful-mahavira-0265a4).

🤖 Generated with Claude Code

[QuantumExplorer]

CORE-10 (Multi-recipient Core send) — now ✅

Surfaced in the UI and driven green on the booted simulator.

Change (UI + marshalling only — no new FFI): the Core→Core send flow now supports N recipient rows. SendTransactionView gains an "Additional Recipients" section with an "Add recipient" button (shown only for the coreToCore flow) and per-row address/amount fields + a per-row Core-address validation badge. SendViewModel.coreRecipients builds the ordered [(address, amountDuffs)] list (primary row + extras), validates every row atomically (each must be a Core address on-network with amount > 0), and passes it straight to the existing ManagedCoreWallet.sendToAddresses(recipients:) wrapper → core_wallet_send_to_addresses. Rust still does coin selection + multi-output tx construction; Swift only collects the pairs and marshals the parallel arrays. A per-output summary section shows each output + Total + Fee before sending.

Verification (testnet, iPhone 17 sim, TestnetWallet → two QA New Wallet addresses):

• Sent 0.001 + 0.002 DASH in one transaction; success alert read "Payment sent to 2 recipients".
• On-chain (insight.testnet): txid 30010050ce9f4f96b6a05ad8d7ab6bacde26b95cacdb98d9e0b0a72c17f840fc, block 1,495,895, txlock: true, 3 vouts — 0.001 → yX6nLg4f…ivHmnh, 0.002 → yW2nW3Xs…kjgsNQ, 0.811… → change. One input → one tx.
• Sender confirmed balance dropped 1.81473134 → 1.81172874 DASH = sum (300,000) + fee (260 duffs).
• Both recipients credited after sync: QA New Wallet now holds 2 UTXOs = 300,000 duffs.
• Incidental: per-row validation correctly flagged "Not a Core address on this network" and disabled Send when a row's address was malformed; Remove recipient works.

Entry point: SendTransactionView (Core→Core) → "Add recipient" → core_wallet_send_to_addresses. TEST_PLAN row + Appendix B updated.

Note: an initial attempt errored with "SPV client is not running" — an environment state (Core SPV not started this session), not a code defect; the same error a single-recipient send hits in that state. Tapping Start on the Sync tab (synced to tip 1,495,893) cleared it and the send went through.

[QuantumExplorer]

📊 Read-only QA status dashboard is live

A web dashboard that visualises this plan's on-chain QA results is now deployed:

• Live: https://dashpay.github.io/qa-dashboard-site/
• Source: https://github.com/dashpay/qa-dashboard-site

It reads the on-chain dash-qa data contract (2qEVUbg4znNgNRs3FJQ4kof4NKpB8q4fGtYa7qBouLzw, testnet) — the testCase / testRun types seeded from TEST_PLAN.md — via the Evo SDK with proof verification. Read-only in v1 (no wallet/signing).

Renders:

• a tier × category status matrix (latest result per cell);
• per-test latest result with the impl-status badge, and a run-history drill-in showing each run's network/build/device, evidence (txid/URL/path), and blocker notes;
• summary counts and filters (network / build / tier / category / result / impl status / search).

It currently shows all 126 seeded test cases; the result cells populate as testRun documents are submitted. Deep links are supported, e.g. ?test=CORE-05 opens a test's history and ?demo=1 loads a sample dataset.

TEST_PLAN.md link added in #3911. Pointing it at a re-registered contract (testnet resets) is a one-line public/config.json change — no rebuild.