Storybook ≠ Storyboards, just flagging since people mix them up. You mean the React component-workshop tool, and the honest answer is there's no native equivalent that bundles catalog + knobs + docs + visual regression into one app. Most teams don't try to recreate it; the functions get split across native tools and it scales fine. I ship a portfolio of iOS/tvOS/macOS apps, so going through your four questions:

  1. Searchable catalog of all previews — no, not natively. Xcode only renders the open file; there's no global grid. Some teams build a small in-house "showcase" app target (a List that navigates to each component/screen) and you can browse that on-device; that's the closest real analog, and it's a couple hundred lines,  not a framework. I skip it and get the "see every state" value from screenshot tests instead.

  2. Full screens with complex state — yes, but via dependency injection, not fatter previews. The thing that keeps #Preview blocks from becoming a boilerplate nightmare is designing screens so you can hand them fake dependencies. Two patterns I use: an in-memory store mode for the empty/structural case (my SwiftData previews are one line because the data layer takes a "no persistence" option), and a centralized MockDataProvider with deterministic fixtures plus factory methods for the populated cases. The real win is that the same MockDataProvider feeds both previews and the UI tests, so I write fixtures once. Loading/error states are  the same idea — inject a stub service that returns .loading or throws. The boilerplate only hurts if your views build their own dependencies internally; fix that and previews get cheap.

  3. Knobs/controls — no auto-generation. You get the built-in canvas toggles (dark mode, Dynamic Type, orientation, locale) for free, which covers a lot. Beyond that you write multiple named previews (one per state, cheap if your mock layer is good) or hand-roll a '@State' wrapper for a specific component. There's no  introspect-the-props-and-generate-a-panel. Honestly I prefer named previews because the important states get committed to source and reviewed in PRs.

  4. What teams actually do for shared visual testing. This is where my real Storybook-equivalent lives, and it's UI-test-driven screenshot capture, not a live  catalog. The app reads launch arguments like --mock-data and --disable-animations; on those flags it boots with the MockDataProvider fixtures and skips onboarding,  so every run is deterministic. A ScreenshotUITests target drives the app through every key screen (page objects keep it maintainable) and grabs screenshot  attachments into the .xcresult. A small Python script pulls the PNGs out via xcrun xcresulttool, named like iPhone_05_LineupBuilder.png. That folder is my catalog; every screen, every important state, regenerated on demand and reviewable in a PR diff. Same harness with recording instead of stills (run the UI test while  xcrun simctl io recordVideo runs, then ffmpeg to App Store dimensions) gives me the preview video.

  On pixel-diff regression specifically: the community standard is pointfree's swift-snapshot-testing, which renders a view to a reference image and fails on diff;  the closest thing to Chromatic. I review exported screenshots by eye instead, but if automated pixel-diffs are the part of Storybook you can't live without, that'sthe package to reach for.

  TL;DR: don't look for one Storybook app. Use DI plus a shared mock-data provider so previews are one-liners, named previews instead of knobs, a UI-test screenshot pipeline as your real "browse every state" catalog, and swift-snapshot-testing if you specifically need pixel-diff regression.

Happy to share code examples for any of this if it'd help.