Public claim level: demo. Mobile apps often hide backend dependency questions in ordinary client code. A reviewer may see a Swift view model, service object, generated wrapper, or target enum and know that it probably points somewhere important, but still need a practical way to ask: which API-client surfaces are visible in static evidence, how strong is that evidence, and where does the evidence stop?

TraceMap's Swift API-client evidence walkthrough exists for that middle ground. It does not say the app ran. It does not say a backend accepted a request. It gives reviewers a static map of supported API-client candidates so review, migration planning, endpoint inventory, and change-risk conversations can start from something inspectable.

The problem: mobile apps hide backend dependencies in client code.

In a Swift app, a backend dependency is not always a tidy route list. It might be a URLSession call, a URLRequest method assignment, an Alamofire request, or a Moya-style target. Those are useful signals during review, but they are easy to overstate. A literal path in source code is a lead. It is not proof that a user reached that endpoint, that authentication succeeded, or that production traffic exists.

Static evidence is still valuable because it gives the team a reviewable starting point. If a migration changes an endpoint family, or a backend team asks which mobile surfaces might mention a path, reviewers can use the static candidates to decide where to inspect next.

What TraceMap can show: static API-client candidates.

TraceMap surfaces supported Swift API-client candidates with rule-backed evidence. The public walkthrough focuses on the evidence shape, not on runtime behavior. A row is useful when it carries the rule ID, evidence tier, coverage label, source location, supporting IDs, limitation, and non-claim together.

The safe sentence is intentionally narrow: "TraceMap found a static Swift API-client candidate where the supported rule could identify the shape." The next question belongs to review: is this still reachable, configured, authenticated, tested, deployed, or relevant to the change? Static evidence gets the question to the right place; it does not answer the runtime half.

The four evidence shapes: URLSession, URLRequest, Alamofire, and Moya.

The walkthrough names four supported evidence shapes so reviewers know what kind of static signal they are reading. URLSession and URLRequest rows use swift.http.urlsession.v1. Alamofire and Moya-style rows use swift.http.client-library.v1. In each case, the row should be read as Tier3SyntaxOrTextual or a documented static candidate unless stronger evidence is explicitly attached.

This helps a reviewer separate "we found a supported client-code pattern" from "the app successfully called this service." That distinction is the whole point. The candidate can feed endpoint inventory, migration planning, and change-risk conversations, while runtime questions stay with telemetry, logs, traces, tests, source review, and owners.

How to read a row.

Start with the rule ID. It tells you which extractor rule produced the candidate. Then read the evidence tier and coverage label. A syntax-backed row with reduced coverage should never be repeated with the same confidence as compiler-resolved or runtime evidence. Next, keep the limitation beside the claim. If the row says the evidence is a static URLSession candidate, repeat that boundary in the review packet.

A safe handoff might say: "This Swift file contains a static API-client candidate from swift.http.client-library.v1 with Tier3SyntaxOrTextual evidence and reduced coverage. Reviewers should inspect owner context before making runtime or backend conclusions." That sentence gives the next person enough context without turning the row into endpoint reachability proof.

What this does not prove.

The Swift API-client walkthrough is not runtime tracing. It does not prove endpoint reachability, backend compatibility, request success, auth flow correctness, production traffic, API correctness, app navigation, rendered UI, release safety, deployment state, package compatibility, stored values, query execution, live schema, or complete Swift semantic analysis.

It also does not turn TraceMap into AI impact analysis. TraceMap core scanning and reduction do not use LLM analysis, prompt-based classification, embeddings, or vector databases. The public story stays useful because it stays bounded to deterministic static evidence.

Where to go next.

Start with the Swift API-client walkthrough for the row-level reading guide. Use Swift surface discovery for the broader surface story, then check the real-world smoke proof for pinned public samples and sanitized generated summaries. Before repeating a claim, use the Swift claim-language checklist so rule ID, evidence tier, coverage label, limitation, and non-claim travel with the sentence.