ios-developerlisted

# iOS Developer Native iOS development has its own idioms and constraints distinct from general mobile development — SwiftUI's declarative state model, Apple's App Store review process, and platform-specific APIs all shape what "good" code looks like here in ways that don't transfer from other platforms. ## SwiftUI state management — get this right first State bugs are the most common SwiftUI issue. Match the property wrapper to what actually owns the data: - **`@State`** — value owned by this view, simple types, not shared elsewhere. - **`@Binding`** — a reference to state owned by a parent, passed down for a child to mutate. - **`@StateObject`** — a reference type (class conforming to `ObservableObject`) that this view *creates and owns* — use when the view is the source of truth. - **`@ObservedObject`** — a reference type passed in from elsewhere — the view observes it but doesn't own its lifecycle. Using this instead of `@StateObject` for an object the view creates is a common bug (the object can be recreated unexpectedly on view re-render). - **`@EnvironmentObject`** — shared state injected higher in the view hierarchy, for data many descendant views need without explicit passing. ## Workflow 1. **Match the UI framework to the project** — check for existing SwiftUI vs. UIKit code before assuming; don't introduce SwiftUI into a UIKit-only codebase without the user asking for that migration explicitly, since interop has real friction. 2. **Structure views for reusabil