Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Swift · Question Set
iOS / SwiftUI Fundamentals interview questions for placements and exams.
Questions
10
Included in this set
Subject
Swift
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Swift.
In SwiftUI `@State` is for local mutable state inside a view. `@Binding` is used to pass a reference to that state into child views so they can read/write it. This separation allows parent-child communication of state without giving full ownership to child. This is a common topic in SwiftUI interview Q&A.
For complete preparation, combine this set with full subject-wise practice for Swift. You can also explore other subjects and sets from the links below.
In SwiftUI `@StateObject` is used when a view *creates and owns* an instance of a reference-type model (`ObservableObject`) and you want it to persist for the view’s lifetime. `@ObservedObject` is used when the view *receives* a reference to a model created elsewhere; the view doesn’t own it but observes changes. `@EnvironmentObject` is used when you place a shared model in the environment so many descendant views can access it, and it must be injected. /n/n Choosing between them depends on ownership and lifecycle: use `@StateObject` for root-level creation, `@ObservedObject` for child views receiving models, and `@EnvironmentObject` when data is truly shared across many views. Understanding these distinctions shows strong SwiftUI architecture knowledge.
SwiftUI uses a declarative syntax: you declare what your UI should look like based on current state, and the framework updates the view automatically when state changes. This contrasts with older frameworks like UIKit where you imperatively create and update views. Understanding this shift is fundamental in modern iOS/Swift interviews. (See discussion on SwiftUI’s declarative model)
In SwiftUI views are typically defined as `struct`s to leverage value semantics, which avoids the complexity of shared mutable state inherent in reference types. Using structs aligns with the declarative model: views are lightweight descriptions of UI, and changes in state cause new view values rather than mutating existing ones.
The `@State` property wrapper is used to declare internally mutable state for a SwiftUI view structure. When the value changes, the framework recomputes the body of the view. Other wrappers like `@ObservedObject` or `@EnvironmentObject` are used for external or shared model objects. Knowing when to use each is important in interview discussions.
In SwiftUI for iOS 16+ Apple introduced `NavigationStack` which allows for more flexible and predictable navigation flows (including programmatic path based). While `NavigationView` is still supported, using `NavigationStack` is preferred going forward. This is part of modern SwiftUI patterns often discussed in interviews.
A `ViewModifier` is a protocol in SwiftUI that you implement to encapsulate a transformation or styling of a view that can be reused. For example you may define a custom modifier for a standard button style. In interviews you may be asked to design or show how you’d structure modifiers for consistent styling in SwiftUI.
Combine is Apple’s reactive framework and in SwiftUI you often define a view model conforming to `ObservableObject`, with properties annotated with `@Published`. When these change, SwiftUI views subscribed via `@ObservedObject` or `@EnvironmentObject` automatically refresh. This pattern is frequently discussed in iOS/SwiftUI interviews.
SwiftUI offers a declarative UI model where UI is a function of state. It supports live previews, cross-platform code for iOS/macOS/watchOS, reduced boilerplate, and built-in animations and adaptivity./n/n However, SwiftUI is still evolving: some components or behaviours may be missing compared to UIKit, many existing apps are built in UIKit, and advanced customizations or legacy code may require UIKit integration. You may choose SwiftUI for new projects, especially if you target multiple Apple platforms or value rapid development; use UIKit when you need fine-grained control, have legacy dependencies or complex custom views.
In SwiftUI you need to consider view-body re-computation, identifiability of views, expensive computations inside `body`, large view hierarchies and animations. You can mitigate by using `@State` and `@ObservedObject` carefully to limit re-renders, breaking views into smaller components, using `EquatableView`, marking constant views with `.id`, caching expensive results, lazy stacks/lists, avoiding heavy work in `body`, and profiling with Instruments. This kind of question often separates strong candidates in iOS/SwiftUI interviews.