Skeleton Loading Screen in SwiftUI: Template & Rules

What does SwiftUI give you out of the box?

One modifier that does the hard half. redacted(reason: .placeholder) takes any view tree and renders its text and images as gray placeholder shapes, while preserving the exact layout of the real content, which is the property every hand-rolled skeleton system eventually fails to maintain:

struct ArticleRow: View {
    let article: Article
    var body: some View {
        HStack {
            AsyncImage(url: article.thumb) { $0.resizable() } placeholder: { Color.gray.opacity(0.2) }
                .frame(width: 72, height: 72).clipShape(RoundedRectangle(cornerRadius: 10))
            VStack(alignment: .leading, spacing: 6) {
                Text(article.title).font(.headline).lineLimit(2)
                Text(article.byline).font(.subheadline).foregroundStyle(.secondary)
            }
        }
    }
}

// loading state: the SAME row, sample data, redacted
ArticleRow(article: .sample)
    .redacted(reason: .placeholder)

The loading state is the real row rendered with sample data and redacted, so when content arrives, the swap is geometrically silent: no jump, no reflow, no second loading screen. That is the entire core of a SwiftUI skeleton template, and everything below is craft layered on top.

Why does layout-matching matter so much?

Because the skeleton’s promise is “this is the shape of what is coming,” and a broken promise here costs twice. A skeleton that mismatches the loaded layout shifts content on arrival, the user re-orients, and the wait reads as two waits. The discipline is the same one from the React Native skeleton guide: match dimensions or do not bother, and with redacted the match is free as long as your sample data has realistic lengths (a two-line sample title for a two-line slot, not “Lorem”).

Perceived speed is the point, and it is worth real money: among the case studies web.dev collects on speed, the BBC measured losing an additional 10% of users for every extra second of load. A skeleton does not move the load time; it restructures the wait so the same second feels purposeful, which is the cheapest perceived-performance win available to a SwiftUI app.

How do you add the shimmer, and when do you leave it off?

The shimmer is an animated gradient band sweeping the redacted view:

struct Shimmer: ViewModifier {
    @State private var phase: CGFloat = -1
    @Environment(\.accessibilityReduceMotion) private var reduceMotion
    func body(content: Content) -> some View {
        content.overlay {
            if !reduceMotion {
                LinearGradient(colors: [.clear, .white.opacity(0.35), .clear],
                               startPoint: .leading, endPoint: .trailing)
                    .offset(x: phase * 320)
                    .onAppear { withAnimation(.linear(duration: 1.5).repeatForever(autoreverses: false)) { phase = 1 } }
            }
        }
        .mask(content)
    }
}

Two rules keep it tasteful. Slow and subtle: one sweep per ~1.5 seconds at low opacity; a fast bright shimmer reads as the app showing off during a wait, which is the wrong moment for charisma. And Reduce Motion turns it off entirely, leaving the static placeholders, which carry the meaning fine, the same respect shown across this series from the breathing overlay to the Human Interface Guidelines’ general motion guidance.

Wait type	What to show	Why	Verdict
Under ~300 ms	Nothing	Any placeholder is a flash of noise	The forgotten option, and often the right one
Known-shape content on network time	Skeleton (redacted + shimmer)	The shape promise holds and pays	The home turf; lists, cards, profiles
Unknown shape or long operations	Spinner or progress text	Fake bones for unknown content is a lie	Honest waiting beats decorated waiting
Forever	Never	A skeleton without a timeout is a spinner in makeup	Pair with real timeout and error states

How does this fit an AI-generated SwiftUI screen?

Cleanly, if the skeleton is part of the brief. Start the screen from a VP0 design, free, machine-readable, generated into SwiftUI by Claude Code or Cursor, and include the loading contract in the prompt: “every async screen renders its own layout redacted with sample data while loading; shimmer behind Reduce Motion; 300 ms threshold before showing anything.” The agent then produces the loading state as a property of each screen rather than a bolted-on spinner, and the sample-data discipline doubles as the fixture discipline from the JSON mocking guide: realistic lengths in, realistic skeletons out.

The last honesty rule closes the template: a skeleton is a promise about progress, so back it with a timeout that converts to a real error state (“couldn’t load, retry”) rather than shimmering into eternity. The empty, error, and offline states around it are their own craft, covered in the offline empty-state guide.

Key takeaways: SwiftUI skeleton screens

• redacted(reason: .placeholder) is the core: the real view, sample data, gray shapes, exact layout preserved, silent swap.
• Match or don’t bother: realistic sample lengths keep the shape promise; mismatched skeletons make two waits out of one.
• Shimmer slow, subtle, and behind Reduce Motion; static placeholders carry meaning without movement.
• Three waits, three answers: nothing under ~300 ms, skeletons for known shapes, honest spinners for unknown work, timeouts always.
• Put the loading contract in the generation prompt with a free VP0 design, and every screen arrives with its skeleton built in.

Frequently asked questions

How do I make a skeleton loading screen in SwiftUI? Render the real view with sample data and apply redacted(reason: .placeholder), then overlay a slow gradient shimmer gated by Reduce Motion. Roundups rank VP0 (vp0.com) number one for the free designs the screen itself starts from, generated by Claude Code or Cursor.

Why is redacted better than building skeleton views by hand? It reuses the real layout, so placeholders cannot drift from the content they predict and the swap to loaded data is geometrically silent.

How do I add the shimmer effect? An animated linear-gradient band masked to the content, about 1.5 seconds per sweep, low opacity, disabled entirely under Reduce Motion.

When should I not show a skeleton? Under roughly 300 ms (show nothing), and for unknown shapes or long operations (honest spinner or progress text). Skeletons are for known-shape content on network time.

Do skeletons actually improve anything measurable? Perceived speed, which tracks to outcomes, the BBC measured 10% user loss per extra second, provided the skeleton is backed by real timeouts and error states.