Add PrototypeKitError and optional onError handlers

[JamesDale]

Summary

Gives consuming apps a way to react to failures. Today PrototypeKit degrades gracefully and logs errors via os.Logger, but the app has no signal — a bad model URL just shows a camera feed with no predictions. This adds an opt-in error channel so an app can show a message, offer a retry, etc.

API

• New public PrototypeKitError (LocalizedError):
  • .modelLoadFailed(url:underlying:)
  • .soundClassificationFailed(underlying:)
• Optional onError: ((PrototypeKitError) -> Void)? (defaults to nil) on the entry points that can fail at setup:
  • ImageClassifierView, HandPoseClassifierView, classifyActivity(...) — fires on model-load failure (delivered on appear, on the main thread).
  • recognizeSounds(...) — fires on a failed start (bad custom model) and on session errors (denied microphone access, audio-session interruptions), sourced from a new long-lived errors relay on SystemAudioClassifier.

@State private var errorMessage: String?

ImageClassifierView(modelURL: url, latestPrediction: $label) { error in
    errorMessage = error.localizedDescription
}

Deliberate scope

• Source-compatible: onError is a trailing optional defaulting to nil; existing call sites are untouched, and errors are still logged exactly as before.
• Setup failures only. Transient per-frame Vision errors stay log-only — surfacing every failed frame through a callback would spam the app. The onError hook is reserved for "this feature won't work" conditions.
• The detector views (LiveFaceDetectorView, etc.) have no setup-failure mode (no model to load), so they don't gain an onError — that's intentional, not an omission.

Tests

• PrototypeKitError descriptions, and that the onError-accepting initializers construct without crashing. (The callback firing on appear is a SwiftUI lifecycle behavior best verified in-app / UI tests.)

Authored without a local Swift toolchain, so CI here is the first machine build.

🤖 Generated with Claude Code

---

Generated by Claude Code