Async AI workflows in SwiftUI need a failure state, not only a loading spinner

Using Swift
1

Many SwiftUI examples stop at loading and success. That is fine for a
small demo, but an AI-backed feature has more states to explain:

  • the request was queued;
  • the model or network timed out;
  • the response was incomplete or invalid;
  • the user is offline;
  • the server needs a retry or human review.

I am working on a small mobile client for an AI workflow and am trying to keep
the state model honest. The client should not guess whether a request worked.
It should show the current state and let the user retry safely.

The shape I am testing is roughly:

enum WorkflowState<Value> {
    case idle
    case loading
    case succeeded(Value)
    case retryableFailure(message: String)
    case failed(message: String)
}

The important part is not the enum name. It is keeping transport failure,
invalid output, and a deliberate server-side review state separate. That makes
the UI clearer and gives the backend better feedback about what happened.

For people building SwiftUI clients for AI or real-time services: which state
do you find most useful to expose directly to users, and which one do you keep
inside the client model?

More context: Daniel's engineering notes.

2

SwiftUI is a Apple Specific Framework, Questions relating to Apple Specific questions should be directed toward developer.apple.com/forums. This forum is for discussions on the Swift Programming Language and Related Projects.