1. Ignoring State Management Evolution
This is the big one. SwiftUI’s state management story has evolved significantly, but many teams are still stuck in 2020. They might be overusing `@ObservedObject`, leading to unnecessary view re-renders, or creating complex chains of `@Binding` that are hard
to debug. When Apple introduced `@StateObject`, it was a clear signal to rethink object lifecycles. More recently, the Observation framework (using `@Observable`) made things even simpler and more performant. Every WWDC, Apple’s sample code and sessions showcase the *newest* and best way to manage state. When your team sees a new state management tool, the reaction shouldn't be, "We don't need that." It should be, "What problem is Apple trying to solve for us?" Sticking with legacy patterns not only hurts performance but also creates a codebase that becomes progressively harder to modernize.
2. Building Monolithic, UIKit-Style Views
Teams coming from UIKit often carry over old habits. The most common is building massive, monolithic `View` structs that handle everything: state, business logic, and complex layouts. This completely misses the point of SwiftUI, which is designed for small, composable, and reusable views. Look at any of Apple’s own SwiftUI examples—they are a tapestry of tiny, focused views woven together. When a single file scrolls for pages and contains dozens of nested `HStack` and `VStack` blocks, you’ve lost the plot. The cost isn't just readability; it's performance. SwiftUI is optimized to update small, independent parts of the view hierarchy. A monolithic view forces the engine to re-evaluate a huge chunk of code for even the smallest state change, leading to sluggish UIs that drain battery life.
3. Abusing `AnyView` as a Crutch
In the early days of SwiftUI, returning different view types from a function was tricky, and `AnyView` seemed like a magical solution. It type-erases a view, letting you return it from a function without specifying the exact concrete type. But Apple’s engineers have repeatedly warned that this comes at a steep performance cost. Using `AnyView` breaks SwiftUI’s ability to understand the view hierarchy. It can’t efficiently diff the changes, so it often has to throw away and rebuild entire sections of your UI. Modern SwiftUI offers better solutions, like `@ViewBuilder` function builders and `if/else` or `switch` statements directly in the body. If you see `AnyView` sprinkled throughout your codebase, it's a code smell. It’s a sign that the developer didn’t know how to properly structure their view logic, and now the app is paying the price in performance.
4. Misunderstanding View Identity
This is a more subtle but equally damaging mistake. In SwiftUI, view *identity* is crucial for animations, state preservation, and performance. When the identity of a view changes, SwiftUI considers it a completely new view, destroying the old one and its state. A common mistake is using a loop, like `ForEach`, without providing a stable and unique identifier for each element. Using an array index as an ID, for example, is a recipe for disaster if the array can be reordered or items can be deleted. WWDC performance sessions often touch on how crucial stable identities are. The `.id()` modifier is another tool that is frequently misused, applied to solve a layout bug when it’s really meant to manually manage identity. Getting this wrong leads to bizarre UI glitches, disappearing state, and janky animations that leave users frustrated.
5. Fetching Data in the Wrong Place
Where and when do you kick off a network request? Many developers, especially those new to the framework, are tempted to do it in a view’s `init()`. This is a huge anti-pattern. A view’s initializer can be called many times, often in situations you wouldn’t expect, leading to a flood of redundant network requests. Apple has provided clear guidance here. The `.onAppear` modifier was an early solution, but it had its own quirks. The modern, correct approach is the `.task` modifier. It ties the lifecycle of an asynchronous operation directly to the lifecycle of the view. When the view appears, the task starts. If the view disappears before the task is done, SwiftUI automatically cancels it. This prevents leaks, saves network bandwidth, and ensures your data-fetching logic is predictable and efficient. Ignoring this pattern is like leaving the faucet running—it's wasteful and will eventually cause a flood.
