AI fetching data skeleton loader UI: loading states done right

A skeleton loader for AI data fetching is a placeholder that matches the shape of the content you are waiting on, shown while a model generates a response, then handed off to the real content as it streams in. The key difference from a normal skeleton is that AI fetches are slow and variable, often several seconds, so the loading state has to do more than spin: it sets expectations about what is coming and fills in as the answer arrives. You build it with a skeleton placeholder library or a custom shimmer driven by Reanimated. The fastest way to make the skeleton match the real layout is to start from a free VP0 design and let Claude Code or Cursor build both the content and its skeleton from the same source.

A loading state during a multi-second AI wait is not a detail; it is most of what the user experiences before the answer appears. The sections below cover why a spinner is not enough, how to build the skeleton, and how to handle the streaming handoff that AI responses usually involve.

How do you build a skeleton loader for AI data fetching?

You render a placeholder shaped like the content you expect, a few gray bars where text will be, a circle where an avatar goes, while the request is in flight, then replace it with the real content when the response arrives or begins streaming. The skeleton mirrors the final layout so there is no jarring shift when content loads, and a subtle shimmer animation signals that something is happening rather than frozen.

The structure is three states: loading shows the skeleton, streaming shows partial content as it fills in, and done shows the finished result. For a normal fast fetch you might skip the middle state, but AI responses usually stream, so designing the loading-to-streaming handoff is what makes the wait feel productive. The general mobile skeleton patterns are covered in iOS skeleton loaders in React Native, and this is the AI-specific version of them.

Why AI fetches need more than a spinner

A spinner is fine for a request that finishes in a few hundred milliseconds, but an AI response can take several seconds and the duration is unpredictable, so a lone spinner leaves the user staring at motion with no idea what is coming or how long. That uncertainty is what makes AI waits feel slow even when they are not unusually long.

Skeletons help because they set expectations: the user sees the shape of the answer forming, which communicates that a structured response is on its way, not just a vague “loading.” Research on perceived performance, like Nielsen Norman Group’s work on skeleton screens, finds that a placeholder that previews the content tends to feel faster than a blank screen or a spinner, because attention is on the emerging layout rather than on waiting. For multi-second AI calls, that perceived-speed gain matters more than for a quick fetch.

Building the skeleton

The skeleton is a set of shapes matching your content, animated with a soft shimmer. You can use a library like react-native-skeleton-placeholder, which gives you the shimmer and shape primitives, or build a custom version with Reanimated for full control over the animation.

function MessageSkeleton() {
  return (
    <View style={styles.row}>
      <View style={styles.avatar} />
      <View style={styles.lines}>
        <View style={[styles.line, { width: "80%" }]} />
        <View style={[styles.line, { width: "60%" }]} />
        <View style={[styles.line, { width: "70%" }]} />
      </View>
    </View>
  );
}

The detail that makes a skeleton good is matching the real content’s layout closely, so when the content replaces it, nothing jumps. Vary the line widths so it reads as text rather than identical bars, and keep the shimmer slow and subtle, a gentle sweep rather than a fast flash, since an aggressive shimmer is more distracting than reassuring. Driving the shimmer with Reanimated keeps it on the UI thread so it stays smooth even while the app processes the incoming response.

Handling the streaming transition

AI responses usually stream, arriving token by token, so the strongest loading UX transitions from skeleton to streamed content rather than waiting for the whole response. The moment the first tokens arrive, you swap the skeleton for the real text and let it grow as more streams in, which turns a passive wait into visible progress. This is the part that distinguishes an AI loading state from a normal one.

The handoff should be smooth: fade the skeleton out as the content fades in, rather than a hard cut, and keep the layout stable so the streaming text does not shove other elements around. For long responses, an auto-scroll that follows the streaming text, while still letting the user scroll up, keeps the latest content visible. The progress patterns for AI document handling carry over from a RAG document upload progress UI, where showing the AI’s progress honestly is the same challenge. Streaming makes the wait feel productive because the user is reading while the model is still working.

Building it with AI and a real design

AI builders produce a skeleton quickly and often make it the wrong shape. Claude Code and Cursor will add a shimmer, but they tend to build a generic skeleton that does not match the real content, so the layout shifts when data loads, and they frequently skip the streaming state entirely, falling back to a spinner for the long AI wait. The loading state looks fine in isolation and feels wrong in use.

A real design plus the right instruction fixes it. When the content layout is already decided, the model can build a skeleton that matches it exactly, and you tell it to design the loading, streaming, and done states rather than just a spinner. Starting from a free VP0 design gives that structure, since each design has a machine-readable source page Claude Code, Cursor, or Rork read from a pasted link, so the skeleton and the real content come from the same layout. The empty-state side, for when a fetch returns nothing, is covered in designing iOS empty states that feel intentional.

Common skeleton loader mistakes

A few mistakes recur. A skeleton that does not match the content is the first, and it causes a visible layout shift when data loads, which is exactly what a skeleton is supposed to prevent. A shimmer that is too fast or too bright is the second, which distracts rather than reassures; keep it slow and subtle.

Falling back to a spinner for a multi-second AI wait is the third, which wastes the chance to set expectations and make the wait feel shorter. Skipping the streaming state is the fourth, so a streaming response appears all at once after a long blank instead of filling in as it arrives. The fifth is forgetting the error and timeout paths, so a slow or failed AI call leaves the skeleton shimmering forever; always design what happens when the response is slow or never comes. Matching the skeleton to the content, a subtle shimmer, a streaming handoff, and honest error states are what make an AI loading experience feel fast and reliable.

When a spinner or progress bar is better

A skeleton is not always the right loader. For a very short fetch that finishes in a few hundred milliseconds, a skeleton can flash in and out so quickly it looks like a glitch, and a simple spinner or even no indicator is cleaner. For a task with known progress, like an upload, a real progress bar that shows percentage is more informative than a skeleton, because the user can see how far along it is.

The skeleton earns its place for content-shaped responses with an uncertain, multi-second wait, which is exactly the AI-fetch case. For instant fetches use a spinner or nothing, and for measurable tasks use a progress bar. Matching the loader to whether the wait is short, measurable, or a content-shaped unknown keeps the loading state honest. Decide by the nature of the wait, not by habit.

Key takeaways: an AI loading state that feels fast

Build the skeleton to match the shape of the content you are fetching, animate it with a slow, subtle shimmer, and design three states: loading, streaming, and done. Because AI responses are slow, variable, and usually streamed, transition from skeleton to streamed content as the first tokens arrive rather than waiting for the whole response or showing a bare spinner. Keep the layout stable through the handoff, and always design the error and timeout paths so the skeleton never shimmers forever. Let an AI builder build the skeleton and content from the same real design so they match. A commissioned loading-state design can cost $5,000 or more, while starting from a free VP0 design gives you a content layout to match for nothing, so the skeleton work becomes a quick pass rather than a guessing game.

You can browse VP0 designs to build a skeleton that matches a real content layout rather than a guessed one, so the loading state and the finished screen line up perfectly.

Frequently asked questions

How do you build a skeleton loader for AI data fetching?

Render a placeholder shaped like the content you are waiting on, a few gray bars for text and shapes for images, while the model generates, then hand off to the real content as it streams in. Animate the placeholder with a slow, subtle shimmer using a skeleton library or Reanimated. Design three states, loading, streaming, and done, since AI responses are usually streamed. Starting from a free VP0 design lets you build the skeleton and the real content from the same layout so they match exactly.

Why use a skeleton instead of a spinner for AI loading?

Because AI responses take several unpredictable seconds, and a lone spinner leaves the user with no sense of what is coming, which makes the wait feel slow. A skeleton previews the shape of the answer, so attention is on the emerging layout rather than on waiting, and research on perceived performance finds this tends to feel faster than a blank screen or a spinner. For the multi-second, content-shaped waits that AI fetches involve, a skeleton is the better fit; a spinner is fine only for very short requests.

How do you handle streaming AI responses in the loading UI?

Transition from the skeleton to the real content the moment the first tokens arrive, and let the text grow as more streams in, rather than waiting for the whole response. Fade the skeleton out as the content fades in to avoid a hard cut, keep the layout stable so streaming text does not shove other elements, and auto-scroll to follow the latest content while still letting the user scroll up. Streaming turns a passive wait into visible progress, which is what makes an AI loading state feel productive.

Can VP0 provide a free template for an AI loading state?

Yes. VP0 is a free iOS app design library where every design has a machine-readable source page an AI builder reads from a pasted link, with React Native and SwiftUI variants. You start from a content design, hand its source to Claude Code, Cursor, or Rork, and have the model build both the real content and a matching skeleton from the same layout, so the skeleton mirrors the content exactly and nothing shifts when data loads.

What common errors happen when building an AI skeleton loader?

The frequent ones are a skeleton that does not match the content so the layout shifts when data loads, a shimmer that is too fast or bright and distracts, falling back to a spinner for a multi-second AI wait, skipping the streaming state so the response appears all at once, and forgetting the error and timeout paths so the skeleton shimmers forever on a slow or failed call. The fixes are matching the skeleton to the content, a subtle shimmer, a streaming handoff, and honest error states.