iOS Developer interview questions

SwiftUI Views are transient value descriptions, while durable state is stored through state-management mechanisms outside an individual View value.

• SwiftUI can create new View values whenever inputs change, so a View struct should not be treated as a persistent UI object.
• Property wrappers connect the description to storage owned by the framework, another object, or the environment.
• State changes invalidate dependent parts of the hierarchy and cause SwiftUI to recompute their body values.

@State gives a View identity local source-of-truth storage for a small mutable value.

• SwiftUI owns the storage and preserves it across new instances of the same View identity.
• Mutating the wrapped value invalidates body computations that read it.
• The property should be private when it is an implementation detail, and its initial value should not be used as an external synchronization channel.

@Binding provides read-write access to state owned elsewhere without taking ownership of that storage.

• A parent commonly passes $property to a child that needs to edit the value.
• Reading the binding returns the current source value, and writing it updates that same source.
• A Binding can also be constructed with custom get and set closures to adapt an existing state model.

ObservableObject exposes change notifications, and @Published emits those notifications when a marked property is about to change.

• ObservableObject provides an objectWillChange publisher used by SwiftUI observation.
• @Published creates a publisher for the individual property as well as participating in the enclosing object's change signal.
• Changes must occur on the appropriate actor for UI use, commonly by isolating the observable model to @MainActor.

@ObservedObject is appropriate when a View observes an ObservableObject whose lifetime is owned outside that View.

• The wrapper subscribes the View to object change notifications.
• Recreating the View does not establish stable ownership of a newly initialized object.
• Parent injection or another external owner should keep the observed instance alive for the required lifetime.

@StateObject is appropriate when a View identity creates and owns the lifetime of an ObservableObject.

• SwiftUI initializes the object once for that identity rather than on every View value reconstruction.
• Object change notifications still invalidate dependent UI like they do with @ObservedObject.
• The storage ends when the owning View identity leaves the hierarchy.

Replacing @StateObject with @ObservedObject removes the View's framework-managed ownership of the object.

• An object initialized inline with @ObservedObject may be recreated as new View values are produced.
• Reinitialization can reset state and repeat subscriptions or other initialization work.
• If an external owner already supplies the instance, @ObservedObject is correct because adding a second owner would misrepresent the data flow.

@EnvironmentObject retrieves a shared ObservableObject supplied by an ancestor in the SwiftUI environment.

• It avoids passing the same object explicitly through every intermediate View.
• Resolution is type-based, so the hierarchy must contain a matching environmentObject injection.
• It suits genuinely shared dependencies, but excessive use can hide a View's requirements and complicate previews or tests.

@Environment reads a value identified by an environment key, while @EnvironmentObject resolves an observable reference by type.

• Environment values include system inputs such as locale, color scheme, and dismiss actions.
• Custom EnvironmentKey definitions can propagate lightweight values or dependencies.
• @EnvironmentObject specifically observes an injected ObservableObject and requires that object to exist in the ancestor hierarchy.

SwiftUI associates state storage with a View's structural or explicit identity rather than with a particular struct instance.

• Keeping the same identity lets @State and @StateObject storage survive body recomputation.
• Changing identity with a different branch, position, or id can discard old storage and create new storage.
• Stable identity is therefore part of the correctness of lists, conditional hierarchies, and stateful child Views.

A Publisher produces a typed sequence, a Subscriber receives it, and a Subscription connects them and manages demand and cancellation.

• A Publisher declares both Output and Failure types.
• A Subscriber receives a subscription, zero or more values, and at most one completion.
• The Subscription lets the subscriber request demand and cancel further delivery.

Every Combine Publisher specifies the value type it emits and the error type with which it can fail.

• A publisher that cannot fail uses Never as its Failure type.
• Operators must preserve or deliberately transform compatible Output and Failure types.
• mapError, setFailureType, catch, and replaceError adapt the failure channel for downstream composition.

An AnyCancellable represents cancellation ownership, and releasing it cancels the associated subscription.

• sink and assign commonly return an AnyCancellable for the created subscriber.
• Storing it in a property or Set keeps the subscription active for that owner's lifetime.
• Cancelling explicitly or releasing the storage stops future delivery and breaks the subscription chain.

PassthroughSubject forwards new values only, while CurrentValueSubject also stores and exposes a current value.

• A new PassthroughSubject subscriber receives nothing until the next send.
• A new CurrentValueSubject subscriber immediately receives its current value before later updates.
• Both can imperatively send values and a terminal completion into an otherwise declarative pipeline.

map transforms each emitted value directly, while flatMap transforms each value into a new Publisher and merges those inner publishers.

• map keeps a one-value-to-one-value relationship and does not introduce another asynchronous stream.
• flatMap is useful when an upstream value starts work represented by a Publisher.
• flatMap does not automatically cancel older inner publishers, so switchToLatest is a separate choice when only the newest stream should remain active.

combineLatest emits from the latest values after each input has emitted once, while zip pairs values by their emission positions.

• combineLatest reacts whenever either upstream updates and reuses the latest value from the other.
• zip waits until it has one unmatched value from each side and consumes them as a pair.
• The choice depends on whether the relationship represents current state or one-to-one event pairing.

subscribe(on:) affects where subscription and upstream work begin, while receive(on:) changes the scheduler used for downstream delivery.

• subscribe(on:) influences subscription, request, and cancellation operations upstream.
• receive(on:) delivers subsequent values and completion on the specified scheduler.
• UI-consuming stages commonly receive on the main scheduler, but unnecessary scheduler hops should not be scattered through a pipeline.

eraseToAnyPublisher hides a concrete publisher chain behind the stable AnyPublisher type.

• Operator chains have long implementation-specific generic types that callers rarely need to know.
• Type erasure prevents implementation changes from leaking into an API signature.
• It preserves Output and Failure types while removing access to concrete publisher-specific operations.

async marks a function that can suspend, and await marks a call where the current task may suspend until an asynchronous result is available.

• Suspension does not block the underlying thread while the task waits.
• An async function can return a value or throw, producing async throws when both behaviors apply.
• await marks a potential suspension point but does not guarantee that suspension or a thread switch occurs.

async let creates a scoped child task for a value that can be computed concurrently with sibling work.

• Several async let bindings begin their child operations before their values are awaited.
• Reading a binding requires await and propagates errors when the child expression throws.
• Unfinished child tasks are awaited or cancelled automatically before the enclosing scope exits.