fix(ios): pin the SDK build that reports where a request's time went

[Makisuo]

Bumps maple-swift to 0.2.1, which records URLSession's connection phases on client spans.

Why

The mobile screens load slowly and maple-api is not the reason. Joining 241 iOS client spans to their own maple-api server span in the same trace:

Phase	p50	p95
Before the server	404 ms	1,148 ms
Server work	233 ms	857 ms
After the server responded	97 ms	759 ms

Two thirds of every request happens outside the API. Home's five requests do fan out in parallel — that part is fine — but in trace 85db338c… the app held two completed responses for 12.6 s, both ending at the same instant, long after the API had answered them in ~220 ms.

Contention is implicated: a request with no concurrent peers has an 89 ms post-server tail; with peers it is 496 ms p50 / 5,820 ms p95, and the request's own payload size does not explain the difference (~18 KB in every bucket).

Why the traces could not say more

The SDK's relay delegate implemented didReceive / didCompleteWithError but not didFinishCollecting, so URLSessionTaskMetrics — which URLSession had been measuring all along — was built and discarded. That is why 404 ms of pre-server time had no attribution.

0.2.1 keeps them. The gap now resolves into maple.http.{queued,dns,connect,tls,request,ttfb,response}_ms, plus maple.http.connection.reused and semconv's http.request.resend_count and network.protocol.{name,version}.

maple.http.queued_ms vs response_ms is what separates "connection setup" from "body transfer stuck behind something", which is the open question.

Scope

Instrument only — no app-side behaviour changes. The fix follows the numbers this produces rather than the current best guess at them.

Two things found along the way, left for separate changes:

• ui.screen spans measure time-on-screen (max observed: 11 hours) and sit in the same latency rollup as real operations, which is why list_services reports maple-ios P95 = 12.62 s. That number is currently meaningless.
• Home fetches /alerts/rules?limit=100 (42 KB) and /error_issues?limit=100 (39 KB), where the issues response is used only to compute two integers. Trimming it needs a count endpoint on the API side.

Verification

• xcodegen generate + xcodebuild -scheme Maple against 0.2.1: BUILD SUCCEEDED
• maple-swift: MapleTracingTests 60 passed (5 new), MapleReplayTests 80 passed

project.yml is the only durable pin — the generated .pbxproj and its Package.resolved are gitignored.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

🍁 Maple PR preview

Note

Preview resources were removed when this pull request closed.

Final commit db2e5bb · View workflow run