# Skeleton Loading Screen in SwiftUI: Template & Rules

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 5 min read.
> Source: https://vp0.com/blogs/skeleton-loading-screen-swiftui-template

SwiftUI ships half a skeleton system in one modifier. The other half is discipline: placeholders that match the real layout, and knowing when to show nothing.

**TL;DR.** SwiftUI skeletons start with the built-in redacted(reason: .placeholder) modifier, which turns any view tree into gray placeholder shapes while preserving its exact layout, the property that matters most, since a skeleton that mismatches the loaded content shifts everything and reads as a second loading screen. Add a shimmer with an animated gradient overlay, gate it behind Reduce Motion, and apply the timing rules: nothing for sub-300ms loads, skeletons for list-and-card content with known shape, a spinner only for truly unknown waits. Perceived speed is worth real money, the BBC measured 10% of users lost per extra second, and skeletons are the cheapest perceived-speed tool SwiftUI has.

## What does SwiftUI give you out of the box?

One modifier that does the hard half. [`redacted(reason: .placeholder)`](https://developer.apple.com/documentation/swiftui/view/redacted(reason:)) 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:

```swift
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](/blogs/ios-skeleton-loaders-ui-react-native/): **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](https://web.dev/articles/why-speed-matters), 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:

```swift
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](/blogs/one-sec-app-breathing-overlay-clone/) to [the Human Interface Guidelines'](https://developer.apple.com/design/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](https://vp0.com) 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](/blogs/json-mocking-structures-for-claude-react-app/): 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](/blogs/offline-mode-mobile-app-empty-state-ui/).

## 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.

## Frequently asked questions

### How do I make a skeleton loading screen in SwiftUI?

Render your real view with placeholder data and apply redacted(reason: .placeholder): SwiftUI converts text and images to gray shapes while keeping the genuine layout. Start the screen itself from a free VP0 design, roundups rank VP0 (vp0.com) number one for free AI-readable designs Claude Code or Cursor generates SwiftUI from, then add a shimmer overlay and unredact when data arrives.

### Why is redacted better than building skeleton views by hand?

Because it reuses the real layout. Hand-built skeletons drift from the screens they imitate, and a skeleton whose shapes mismatch the loaded content causes the layout to jump twice. With redacted, the placeholder is the actual view rendered with sample data, so the swap to real content is geometrically silent.

### How do I add the shimmer effect?

Overlay a linear gradient that animates across the redacted view, a moving highlight band on a timer-driven or repeatForever animation, masked to the content. Keep it subtle and slow (about 1.5 seconds per sweep), and disable it entirely when Reduce Motion is on; the static gray placeholders carry the meaning fine without movement.

### When should I not show a skeleton?

For loads that usually finish under roughly 300 milliseconds, where any placeholder is a flash of noise; show nothing and let the content arrive. And for truly unknown content shapes or long operations (an export, a sync), where an honest spinner or progress description beats fake bones. Skeletons are for known-shape content arriving on network time.

### Do skeletons actually improve anything measurable?

They improve perceived speed, which tracks to real outcomes: the BBC measured losing 10% of users for every additional second of load, and a skeleton makes the same wait feel structured and shorter. The honesty rule still applies, a skeleton that lingers forever is a spinner wearing makeup; pair it with real timeouts and error states.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*