Most AI features don't fail because the model is bad.
They fail because everything around the model is treated like a demo.
This week I was tightening an iOS workout app that uses Claude through Supabase Edge Functions. The model part is straightforward: send training context, get a structured exercise or plan back, validate it, write it into SwiftData.
The less glamorous work was the part that makes it feel like an actual product:
- monthly AI credit balance
- offline handling
- auth token storage
- disabled states while generation is running
- different rules for “add exercise” vs “swap this exercise”
- tests for the boring edge cases
That is where most AI app quality lives.
One button, several states
The UI has a small “fill with AI” affordance on the exercise editor. Underneath it, the button is not just “call endpoint”. It has to know whether suggestion is currently allowed:
var canSuggest: Bool {
guard !isLoadingAI,
NetworkMonitor.shared.isOnline,
(creditsRemaining ?? 1) > 0
else { return false }
// Swap mode can use the original exercise as context.
// Add mode needs the typed name as a hint.
return isSwapMode || !name.trimmingCharacters(in: .whitespaces).isEmpty
}
That little predicate is doing a lot of product work.
If the user is offline, don't let them tap into a doomed network request.
If a generation is already running, don't double-spend.
If they have zero credits, don't pretend the feature is available.
If they are swapping an existing exercise, don't force them to type a name because the old exercise is already useful context.
The model does not care about any of this. The user does.
Credits should be part of the response
The suggestion response includes the updated credit count:
struct SuggestedExercise: Decodable {
let name: String
let briefDescription: String
let muscleGroup: String
let sets: Int
let repTargetLow: Int
let repTargetHigh: Int
let restSeconds: Int
let isDualDumbbell: Bool
let creditsRemaining: Int
}
Then the view model updates local state immediately after a successful fill:
creditsRemaining = result.creditsRemaining
aiFilledFields = true
That avoids the classic AI-product weirdness where the backend knows the user has spent a credit but the UI keeps showing stale allowance until the next refresh.
It is also easier to test. In the app tests, the credit transition is explicit:
func testAIDisabledWhenCreditsReachZero() {
let vm = ExerciseEditViewModel(mode: .add(makeDay()), context: container.mainContext)
vm.name = "Row"
vm.creditsRemaining = 1
XCTAssertTrue(vm.canSuggest)
vm.creditsRemaining = 0
XCTAssertFalse(vm.canSuggest)
}
There are 13 tests just around the exercise edit view model, plus separate coverage for offline error mapping. Not because this is academically interesting, but because this is the stuff that breaks in front of real users.
Offline is not a server error
Another small detail: connectivity failures are mapped separately from backend failures.
static let connectivityCodes: Set<URLError.Code> = [
.notConnectedToInternet,
.networkConnectionLost,
.timedOut,
.cannotConnectToHost,
.dataNotAllowed,
]
The resulting message is intentionally plain:
"You're offline. Reconnect to use AI features."
No “unexpected server response”. No fake intelligence. Just tell the user what happened.
The actual lesson
Shipping AI features is mostly normal software engineering with a probabilistic dependency in the middle.
The model call matters, but the surrounding contract matters more:
- Can the user invoke it right now?
- What happens if the network dies?
- Is usage counted consistently?
- Does the UI reflect server state immediately?
- Are the edge cases testable without calling the model?
Once those pieces are in place, the AI feature stops feeling like a prompt wired to a button and starts feeling like part of the app.
That is the bar I keep coming back to: not “does the model answer?” but “does this survive normal product reality?”
