Practice Pitches

In Swift the big distinction is value types versus reference types. Structs and enums are value types — when you assign or pass them, you get a copy, so there's no shared mutable state to worry about. Classes are reference types: every reference points at the same instance, and they're managed by automatic reference counting.

My default is a struct, especially for models and SwiftUI views, because value semantics make code easier to reason about. I reach for a class when I genuinely need shared identity or reference behavior — for example an observable model object. And the cost of copying is usually a non-issue because Swift's collections use copy-on-write: they only actually copy when you mutate a second reference.

SwiftUI is declarative: a view is a function of state, so I describe what the UI should look like for the current state and the framework diffs and updates the screen when that state changes.

The skill is choosing the right ownership. @State is for state a view owns itself. @Binding is a two-way reference to state owned somewhere else, so a child can edit a parent's value. For shared model objects I use the Observation framework — an @Observable class that I hold with @State and bind into with @Bindable. And @Environment is SwiftUI's built-in dependency injection for things passed down the tree.

The principle underneath all of it is a single source of truth: state lives in one place and flows down as bindings, so the UI is always a consistent reflection of that state.

Modern Swift is built on async/await and structured concurrency. An async function can suspend without blocking a thread, so I write asynchronous code that reads top-to-bottom instead of nesting completion handlers. For parallel work I use async let or a task group — children run concurrently and are awaited, and cancelled, together as a unit.

For shared mutable state I use actors. An actor serializes access to its state, so concurrent callers can't race — it replaces manual locks and queues. And @MainActor guarantees code runs on the main thread, which is where I keep UI and view models, instead of sprinkling dispatch-to-main everywhere.

What ties it together now is Swift 6, which checks all of this at compile time: types crossing concurrency boundaries have to be Sendable, and the compiler enforces actor isolation. So a whole class of data races becomes a build error instead of a crash in production.

I start from the team and the product, not a favorite pattern. For most apps I use MVVM with the Observation framework — thin views, an observable view model with the logic, and dependencies injected behind protocols so everything is testable. When an app gets large and logic-heavy, I'll move toward a unidirectional architecture like TCA, where state lives in one place and changes flow through actions, which makes behavior exhaustively testable.

The decision I care most about at scale is modularization. I split the app into local Swift packages — feature modules that depend on shared Core, DesignSystem, and Networking packages, never on each other. That enforces boundaries, parallelizes builds, and lets features be tested and previewed in isolation.

And I treat production readiness as part of architecture: a router so navigation is just data, observability and crash reporting, and feature flags with phased rollout so I can ship safely and turn something off without a new build.

Rule one: measure before I optimize, because the bottleneck is usually not where I'd guess. I reach for Instruments — Time Profiler for CPU, Allocations and Leaks for memory, the SwiftUI instrument for view-body counts, and Hangs for main-thread stalls.

In SwiftUI most wins come from doing less: keep the view body cheap and pure, give views stable identity so they're reused, use lazy stacks and List for long content, and let the Observation framework re-render only the views that read a changed property. For an image feed specifically, I downsample off the main thread and cache decoded thumbnails — decoding full-resolution images in a small cell is the classic cause of dropped frames and memory spikes.

I want shipping to be boring and repeatable. On every pull request, CI builds the app and runs unit and UI tests plus lint. When something merges to main, CI archives, signs, and uploads a TestFlight build automatically, auto-incrementing the build number.

For a release I promote a TestFlight build to the App Store and use a phased rollout, so the update reaches a growing percentage of users over about a week — if crash rates spike, I can pause it. I use either Xcode Cloud for tight App Store Connect integration, or Fastlane lanes on a CI like GitHub Actions when I want more control, and I manage code signing reproducibly so it's not a person's laptop.

The safety net is crash monitoring plus a feature-flag kill switch, so a bad release can be turned off without waiting for a new build to clear review.

Secrets like tokens and passwords go in the Keychain, which is encrypted and hardware-backed — never in UserDefaults, which is just an unencrypted plist. Sensitive flows get gated with biometrics through the LocalAuthentication framework, always with a passcode fallback.

On the network side I keep App Transport Security on, so connections are HTTPS with modern TLS by default. And on privacy, I declare a privacy manifest with the data the app and its SDKs collect and the required-reason APIs it uses, and I request tracking permission before touching the advertising identifier. The mindset is data minimization — the safest data is the data you never collect, which is also an argument for doing processing on device.

On-device inference wins on four things: privacy, because the data never leaves the device; latency, because there's no network round-trip; offline support; and cost, because there's no per-call bill. Apple accelerates it with the Neural Engine.

The toolbox is Core ML to run trained models, Create ML to train them, and task frameworks like Vision for images, Natural Language for text, and Speech for transcription — and Apple Intelligence is pushing on-device generative features further. My rule is to run on device whenever the task fits, and fall back to a server model only when the work genuinely exceeds what the device can do. A concrete example is semantic search: embed content with a small model, store the vectors locally, and rank by similarity — completely private and offline.