Verify DNS-SD discovery on real iOS and Android devices

[momics]

Summary

The DNS-SD standardization landed in #330 (merged to main as 3ba1ff3) includes mobile-native changes to the Tauri plugin that no CI job compiles or runs — there is no iOS/Android runner. Two of those changes fix real defects and are currently review-only, so their correctness rests entirely on code inspection. We need on-device verification that DNS-SD advertise/browse actually works end-to-end on iOS and Android, and specifically that the two mobile fixes behave as intended.

Evidence

Landed in #330, untested by CI (no mobile toolchain in the pipeline):

• Android — serialized resolve queue (packages/iroh-http-tauri/android/src/main/java/com/iroh/http/IrohHttpPlugin.kt): NsdManager.resolveService() allows only one outstanding resolve; concurrent calls previously failed with FAILURE_ALREADY_ACTIVE and onResolveFailed was a silent no-op, dropping records. Fixed by a shared enqueueResolve/drainResolveQueue that serializes resolves across both the peer (browse_peers_start) and generic (browse_start) paths.
• iOS — re-emit on record change (packages/iroh-http-tauri/ios/Sources/IrohHttpPlugin.swift): the generic browse_start dedup was changed from a one-shot Set<String> to [String: DnsSdRecordSnapshot] so a known instance whose TXT/port/addrs change is re-surfaced instead of being suppressed forever.
• The broader #[cfg(mobile)] command paths, run_mobile_plugin string contracts, and the Swift @objc / Kotlin @Command method names are also only review-verified.

Related: #333 (CI guardrails: native compile + FFI string-parity) — that catches build/contract drift; this issue is about runtime behavior on hardware.

Impact

• Affects Tauri mobile consumers (iOS + Android) of the discovery API — the "standardize across all platforms" goal of feat(discovery): standardize desktop mDNS on DNS-SD for iOS/Android interop #330 is unverified on exactly the platforms it was standardizing for.
• Workaround: desktop (Rust mdns-sd) and the Node/Deno adapters are exercised by CI and verified, so non-mobile usage is unaffected. That's why this is P2 rather than P1.

Remediation

Run a manual on-device pass (physical devices preferred; simulators/emulators as a first cut) covering:

1. Advertise → discover across platforms: advertise from desktop, discover on iOS and Android (and the reverse). Confirm the peer's nodeId resolves and auto-dial succeeds.
2. browsePeers() liveness: confirm discovered peers report isActive: true on arrival and false on expiry (the F-004: cancel_reader does not cancel already in-flight next_chunk await #10 tagged-event fix) on the Tauri adapter specifically.
3. Android concurrency: bring several services/peers up simultaneously and confirm none are dropped (validates the resolve queue; pre-fix this silently lost records).
4. iOS re-emit: change a live service's TXT/port and confirm iOS re-surfaces the updated record rather than suppressing it.
5. Generic surface: exercise node.advertise() / node.browse() (non-peer service) on both platforms; note the documented iOS metadata-only limitation (port: 0, host: undefined).

Capture results (device/OS versions, pass/fail per step) and file follow-up bugs for any divergence.

Acceptance criteria

1. iOS ↔ desktop and Android ↔ desktop advertise/discover verified on-device, with successful auto-dial.
2. browsePeers() reports correct isActive transitions on the Tauri adapter on both platforms.
3. Android multi-peer burst confirmed to drop zero records (resolve queue validated).
4. iOS confirmed to re-emit on a TXT/port change of a known instance.
5. Generic advertise()/browse() exercised on both platforms; iOS metadata-only limitation confirmed to match the documented behavior.
6. Results recorded in this issue (device/OS matrix); any failures filed as linked follow-up issues.

[momics]

Device-pass update (2026-07-12)

Ran the on-device verification (iPhone 12 Pro / iOS 26.5.2 + Nokia 7.2 / Android) against the integration build.

Criterion 1 — advertise → discover → auto-dial: ✅ VALIDATED. Mutual DNS-SD discovery works in both directions and the interop suite runs peer-to-peer at 100% of the real corpus (101 passed / 0 failed / 3 skipped, Android→iOS). This exercises the full advertise→browse→resolve→dial path end-to-end, so the core DNS-SD criterion is proven on real hardware. (Prereq fix landed during the pass: _iroh-http-test._udp added to iOS NSBonjourServices, without which iOS never discovers the harness service.)

Remaining criteria — still to walk (need Test-tab card taps + a desktop/third peer):

• Criterion 2 — browsePeers isActive transitions (peer goes inactive on stop)
• Criterion 3 — Android serialized resolve burst (IROH_DNSSD_CHECK drain-loop ordering under a multi-service burst)
• Criterion 4 — iOS re-emit on TXT change (IROH_DNSSD_CHECK reemit ... event=reemit) — partial captures exist (event=new); needs a live TXT mutation
• Criterion 5 — generic browse port/host logging (IROH_DNSSD_CHECK host:port on the generic path)

These four need the dedicated Test-tab cards and, for 2/3/5, a third (desktop/headless) peer, which conflicts with the running Android dev server (both want vite:1420). Tracking them here as follow-up; the core criterion is validated and unblocks landing.

The one real compliance failure surfaced during the pass (header-user-agent-forwarded, forbidden-header behavior) is split out as #349. The other two mobile↔mobile failures were documented skip cases mis-counted by a Test-tab harness bug (now fixed: filter honors !c.skip).