From swiftui
Delivers SwiftUI performance best practices for view efficiency, data transforms, async work, and structural optimizations like preferring ternaries and LazyVStack.
npx claudepluginhub fradser/dotclaude --plugin swiftuiswiftui-review/references/# Performance - When toggling modifier values, prefer ternary expressions over if/else view branching to avoid `_ConditionalContent`, preserve structural identity, and avoid repeatedly recreating underlying platform views. - Avoid `AnyView` unless absolutely required. Use `@ViewBuilder`, `Group`, or generics instead. - If a `ScrollView` has an opaque, static, and solid background, prefer to use `scrollContentBackground(.visible)` to improve scroll-edge rendering efficiency. - It is more efficient to break views up by making dedicated SwiftUI views rather than place them into computed prope...
/create-viewGenerates a SwiftUI view file with MVVM architecture, property wrappers, layouts, navigation elements, states, accessibility, dark mode support, previews, and documentation.
/convertConvert Claude-generated HTML design from URL or tarball path into SwiftUI View file in active Xcode workspace, with build, error fix, and preview diff.
/design-frameworkConvert HTML/CSS designs to production-ready components for React+Tailwind, Vue+UnoCSS, Svelte 5, Next.js, Astro, Flutter, React Native, SwiftUI, or Jetpack Compose.
/performanceGenerates performance analytics report with learning effectiveness metrics, skill/agent trends, quality visualizations via ASCII charts, and optimization recommendations.
/performanceAnalyzes project performance across frontend, backend, database, and infrastructure, discovers stack, measures metrics, identifies issues, and provides prioritized optimization recommendations.
/performanceRuns performance measurement script on installed plugin files, displaying context overhead, token estimates, component inventory, and codebase stats.
Share bugs, ideas, or general feedback.
_ConditionalContent, preserve structural identity, and avoid repeatedly recreating underlying platform views.AnyView unless absolutely required. Use @ViewBuilder, Group, or generics instead.ScrollView has an opaque, static, and solid background, prefer to use scrollContentBackground(.visible) to improve scroll-edge rendering efficiency.@ViewBuilder on a property or method does not solve this; breaking views up is strongly preferred.task() modifier to be run when the view is shown.body property is called frequently – if logic such as sorting or filtering can be moved out of there easily, it should be.DateFormatter unless they are required. A more natural approach is to use Text with a format, like this: Text(Date.now, format: .dateTime.day().month().year()) or Text(100, format: .currency(code: "USD")).List/ForEach initializers (e.g. items.filter { ... }) when they are repeated often.let, or caching in @State. However, do not cache derived collections in @State unless you also own explicit invalidation logic to avoid stale UI.ScrollView, use LazyVStack/LazyHStack; flag eager stacks with many children.task() over onAppear() when doing async work, because it will be cancelled automatically when the view disappears.@ViewBuilder closures on views when possible; store built view results instead.Example:
// Anti-pattern: stores an escaping closure on the view.
struct CardView<Content: View>: View {
let content: () -> Content
var body: some View {
VStack(alignment: .leading) {
content()
}
.padding()
.background(.ultraThinMaterial)
.clipShape(.rect(cornerRadius: 8))
}
}
// Preferred: store the built view value; the synthesized init handles calling the builder.
struct CardView<Content: View>: View {
@ViewBuilder let content: Content
var body: some View {
VStack(alignment: .leading) {
content
}
.padding()
.background(.ultraThinMaterial)
.clipShape(.rect(cornerRadius: 8))
}
}