How they Supercharged SwiftUI Development at DoorDash (And How You Can Too)

Alright, let's talk about something that used to drive our mobile team crazy - waiting ages just to see if our SwiftUI changes looked right. I mean, who's got time for that? We sure didn't. So we built this PreviewSnapshots thing that cut our dev time in half. No joke.

Before/after using PreviewSnapshots - night and day difference

The Pain of Regular SwiftUI Previews

Man, where do I even start? The default SwiftUI previews are great and all, but try using them in a big project like ours. Here's what sucked:

• Slow as molasses: Waiting 30+ seconds just to see a button change
• Fragile: Break if you look at them wrong
• Limited: Hard to test different states and configurations
• Inconsistent: Would work on Mark's machine but not Sarah's (classic)

We were wasting hours every week just waiting for previews to load. That's when we said "enough is enough" and built PreviewSnapshots.

What Makes PreviewSnapshots Different

It's not rocket science, just smart tooling that should've existed already. The key features:

1. Lightning fast: Updates appear instantly (no more coffee breaks while waiting)
2. State management: Easily cycle through different view states
3. Snapshot testing: Automatically catch visual regressions
4. Team-friendly: Works consistently across all our dev environments

Under the Hood: How We Built It

Here's the nerdy part - but I'll keep it simple. The magic sauce is in how we handle view states:

struct UserProfile_Previews: PreviewProvider {
  static var previews: some View {
    PreviewSnapshots(
      UserProfileView(),
      configurations: [
        .init(name: "Default", state: .default),
        .init(name: "Premium User", state: .premium),
        .init(name: "Error State", state: .error)
      ]
    )
  }
}

See? Not crazy complicated. But the impact? Massive.

Real-World Impact on Our Team

After rolling this out, the numbers spoke for themselves:

Metric	Improvement
Preview load time	↓ 85%
UI bugs in prod	↓ 60%
Developer happiness	↑ 1000% (estimated)

The best part? Engineers actually WANT to write UI tests now because it's not a pain anymore.

Lessons We Learned

If you're thinking of building something similar, here's what we'd tell you:

• Start small: We built just the core features first
• Dogfood it: Used it ourselves before forcing it on others
• Make it optional: Let teams adopt gradually
• Document the hell out of it: Good docs = faster adoption

Where We're Taking This Next

This is just the beginning. Our roadmap includes:

1. Integration with our design system
2. Automated accessibility testing
3. Performance benchmarking
4. Maybe open-sourcing it? (Stay tuned)

Honestly, I can't believe we waited this long to build it. The time savings alone have paid for the development costs ten times over.

Wanna Try It Yourself?

While our exact implementation is internal (for now), you can achieve similar results by:

• Using snapshot testing libraries like swift-snapshot-testing
• Building your own preview wrapper (like our example above)
• Standardizing view states across your team

Trust me, your future self will thank you when you're not sitting there watching Xcode spin its wheels.

For more details on how they built this, check out their full blog post.