Top 30 Uikit Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Why does a symbolic breakpoint on UIViewAlertForUnsatisfiableConstraints help debug Auto Layout in UIKit?

   • aIt behaves like an exception breakpoint but is restricted to Auto Layout warnings only
   • bIt automatically prints the full constraint ambiguity description and continues without stopping
   • cIt resolves to a runtime address without needing UIKit source code and lets you trace back to your code
   • dIt pauses execution before the conflict crashes the app, letting you edit constraints in the view debugger
   Show the answer

   Answer: c · It resolves to a runtime address without needing UIKit source code and lets you trace back to your code

   A symbolic breakpoint stops on a function by name inside closed-source UIKit without requiring source code, and the backtrace reveals which of your methods added the conflicting constraints. Distractor D is tempting because both breakpoints halt execution, but exception breakpoints catch all thrown exceptions broadly, whereas a symbolic breakpoint is precisely targeted to a specific function entry.

   Read the full bite: Explain symbolic breakpoints and debug Auto Layout with one

2. Question 2 of 30

   Which situation most justifies using frame-based layout instead of Auto Layout?

   • aA settings screen that must adapt to iPad split-screen multitasking and device rotation
   • bA button whose intrinsic content size determines its width based on localized text
   • cA custom view that redraws particle effects at 60 frames per second
   • dA table view cell whose layout responds to Dynamic Type changes
   Show the answer

   Answer: c · A custom view that redraws particle effects at 60 frames per second

   Frame-based layout avoids the runtime overhead of constraint solving, making it ideal for high-frequency updates like particle systems at 60 fps. Auto Layout is the right choice for adaptive scenarios such as split-screen multitasking, localized text expansion, and Dynamic Type.

   Read the full bite: When should you use frame-based layout versus Auto Layout?

3. Question 3 of 30

   When does UIKit allocate a new table or collection view cell during scrolling?

   • aOnce for each unique index path when the data is first loaded
   • bOnly during the initial load before any scrolling occurs
   • cWhen the reuse pool has no cell with the requested identifier
   • dEvery time a row scrolls into the visible bounds
   Show the answer

   Answer: c · When the reuse pool has no cell with the requested identifier

   UIKit only creates a new cell when the reuse pool cannot supply one matching the requested identifier; the tempting belief that a new instance is created for every visible row ignores that scrolling primarily recycles existing cells.

   Read the full bite: How do UITableView and UICollectionView reuse cells?

4. Question 4 of 30

   Which statement accurately describes a key architectural difference between UIKit Auto Layout and SwiftUI?

   • aUIKit uses a declarative two-pass sizing system where parents propose sizes to children.
   • bUIKit uses an external constraint solver while SwiftUI uses parent-child two-pass size negotiation.
   • cSwiftUI translates its layout modifiers into Auto Layout constraints under the hood.
   • dSwiftUI relies on an external constraint solver that resolves linear equations to produce view frames.
   Show the answer

   Answer: b · UIKit uses an external constraint solver while SwiftUI uses parent-child two-pass size negotiation.

   UIKit Auto Layout depends on an external solver to resolve linear equation constraints into frames, while SwiftUI layout is driven by an internal two-pass size negotiation between parent and child. Option C represents a common misconception; SwiftUI does not wrap or compile down to Auto Layout constraints but instead uses its own compositional layout engine.

   Read the full bite: Compare UIKit Auto Layout and SwiftUI layout systems

5. Question 5 of 30

   When wrapping a delegate-based UIKit view for use in SwiftUI, what is the correct way to handle callbacks and avoid retain cycles?

   • aProvide a Coordinator object via makeCoordinator and use it as the delegate
   • bConform the UIViewRepresentable struct to the delegate protocol and assign self as the delegate
   • cReassign the delegate inside updateUIView whenever the SwiftUI state changes
   • dWrap the UIKit view in a UIHostingController before adding it to the SwiftUI hierarchy
   Show the answer

   Answer: a · Provide a Coordinator object via makeCoordinator and use it as the delegate

   A Coordinator provides a stable reference to handle delegate callbacks without retain cycles. Making the representable struct the delegate is wrong because structs cannot reliably act as reference-type delegates and it introduces mutability and lifecycle issues.

   Read the full bite: Integrate SwiftUI into UIKit and wrap UIKit for SwiftUI

6. Question 6 of 30

   Two adjacent labels in a row do not fit together. You want the first to stay fully visible and the second to truncate. Which adjustment achieves this?

   • aRaise the first label's compression resistance priority above the second's
   • bRaise the second label's content hugging priority above the first's
   • cLower the first label's intrinsicContentSize to zero
   • dSet both labels' constraints to priority 1000 so neither truncates
   Show the answer

   Answer: a · Raise the first label's compression resistance priority above the second's

   Compression resistance resists shrinking below intrinsic size, so giving the first label higher compression resistance forces the second to truncate. Hugging governs growth, not truncation, and making both required would create an unsatisfiable conflict.

   Read the full bite: How does Auto Layout resolve constraints?

7. Question 7 of 30

   Where should a scene-based iOS app save important user state to avoid data loss, and why?

   • aOnly in viewDidDisappear of the top view controller
   • bIn sceneDidBecomeActive, because that is when the app has the most memory
   • cIn applicationWillTerminate, since it always runs before the app closes
   • dIn sceneDidEnterBackground, because termination from a suspended state may never call a termination method
   Show the answer

   Answer: d · In sceneDidEnterBackground, because termination from a suspended state may never call a termination method

   A suspended app can be killed without applicationWillTerminate ever being called, so saving in sceneDidEnterBackground guarantees state is persisted while code can still run. Relying on termination callbacks risks silent data loss.

   Read the full bite: Describe the iOS app lifecycle and SceneDelegate methods

8. Question 8 of 30

   Which task is explicitly stated as NOT a primary responsibility of a UIView?

   • aResponding to user interactions like touches and gestures
   • bOrganizing other views into a hierarchical structure
   • cManaging application state or performing network operations
   • dRendering visual content within its defined rectangular bounds
   Show the answer

   Answer: c · Managing application state or performing network operations

   The card states that non-visual tasks like network requests, data processing, or managing application state should not live in view code. The other options describe core functions of a UIView.

   Read the full bite: UIView: The Building Block of iOS UIs

9. Question 9 of 30

   What is the root cause of the 'Massive View Controller' problem in UIKit?

   • aMVC forbids creating any classes other than view controllers
   • bDevelopers place networking, parsing, and business logic into the view controller because it is the convenient mediator, not because MVC requires it
   • cThe View communicates directly with the Model, overloading the controller
   • dUIViewController cannot be subclassed, forcing all code into one file
   Show the answer

   Answer: b · Developers place networking, parsing, and business logic into the view controller because it is the convenient mediator, not because MVC requires it

   Controllers bloat because developers funnel unrelated responsibilities into the convenient mediator, a misuse of MVC rather than a rule it imposes. UIViewController is subclassable, and in Cocoa MVC the view does not talk directly to the model.

   Read the full bite: Explain UIKit MVC and the Massive View Controller problem

10. Question 10 of 30

    In an iOS 13+ app using scenes, which task is appropriately handled by SceneDelegate rather than AppDelegate?

    • aSetting up a process-wide Core Data container
    • bHandling a silent push notification to refresh shared data
    • cRestoring user interface state for a specific window session
    • dConfiguring the app's dependency injection container at launch
    Show the answer

    Answer: c · Restoring user interface state for a specific window session

    SceneDelegate owns per-window state restoration and UI lifecycle, whereas AppDelegate manages process-wide singletons and events. Option B is tempting because it occurs in the background, but silent pushes are process-level and must be handled by AppDelegate.

    Read the full bite: How do AppDelegate and SceneDelegate responsibilities differ?

11. Question 11 of 30

    Which statement accurately describes a fundamental characteristic of UIStackView's rendering behavior?

    • aIt automatically applies a default background color to its content views.
    • bIt acts as an invisible layout manager and does not render any visual elements itself.
    • cIt can be directly styled with a background color or border for visual grouping.
    • dIt provides visual debugging outlines that are visible at runtime.
    Show the answer

    Answer: b · It acts as an invisible layout manager and does not render any visual elements itself.

    UIStackView is explicitly described as an "invisible box" and a "non-rendering" class. It manages layout but does not draw any visual content itself, meaning it cannot have a background color or border directly, making option C a common misconception.

    Read the full bite: UIStackView: Layouts Without Manual Constraints

12. Question 12 of 30

    In a Coordinator hierarchy, why does the AppCoordinator typically store active child coordinators in an array?

    • aTo keep flow coordinators alive during their lifecycle and allow parent-controlled cleanup when flows complete
    • bTo enable view controllers to look up the next screen without holding a reference to the coordinator
    • cTo provide a singleton registry where any object can access the current navigation state globally
    • dTo replace UINavigationController with a custom stack that manages all push and pop transitions
    Show the answer

    Answer: a · To keep flow coordinators alive during their lifecycle and allow parent-controlled cleanup when flows complete

    The parent array retains each child coordinator for the duration of its flow and enables cleanup on completion, preventing memory leaks. Option D is tempting but wrong because coordinators decide flow logic; they do not replace UINavigationController or handle transitions directly.

    Read the full bite: How does the Coordinator pattern decouple navigation, and what are its components?

13. Question 13 of 30

    In SwiftUI, how does a ZStack arrange its child views along the Z-axis?

    • aAll views are positioned on the same plane, without any layering effect.
    • bThe first view declared appears at the front, obscuring subsequent views.
    • cViews are layered based on their content size, with larger views always at the back.
    • dThe first view declared is positioned at the back, with subsequent views layered on top.
    Show the answer

    Answer: d · The first view declared is positioned at the back, with subsequent views layered on top.

    A ZStack layers views from back to front, meaning the first view listed is at the back, and the last view is at the front. Option B describes the opposite behavior, which is a common misconception.

    Read the full bite: SwiftUI Stacks: Arrange Views Vertically, Horizontally, and in Layers

14. Question 14 of 30

    What is the primary technical advantage of UITableView's cell reuse mechanism?

    • aIt simplifies the process of applying different styles to various cell types.
    • bIt ensures that all cells maintain a uniform height and layout.
    • cIt allows for dynamic updates to cell content without reloading the entire table.
    • dIt significantly reduces memory usage and improves scrolling fluidity by avoiding constant view creation.
    Show the answer

    Answer: d · It significantly reduces memory usage and improves scrolling fluidity by avoiding constant view creation.

    The card emphasizes that cell reuse prevents a "memory nightmare" and is "far cheaper than creating a new view from scratch," directly addressing memory efficiency and performance. While other options might describe aspects of table view usage, they are not the core technical benefit of the reuse mechanism itself.

    Read the full bite: UITableView: The Backbone of iOS Lists

15. Question 15 of 30

    Why must every container view controller have a non-nil restorationIdentifier during UIKit state restoration?

    • aThey map view controller class names to NSUserActivity entries for scene-based restoration
    • bThey allow UIKit to encrypt the keyed archive that stores the view controller graph
    • cThey signal the system to capture a visual snapshot of that branch for faster relaunch
    • dUIKit uses them to reconstruct the graph structure, so a missing identifier loses the entire branch
    Show the answer

    Answer: d · UIKit uses them to reconstruct the graph structure, so a missing identifier loses the entire branch

    UIKit uses restorationIdentifiers to encode the view controller hierarchy into a keyed archive, so a missing identifier on any container severs that branch entirely. Option C reflects the common misconception that restoration relies on manual visual snapshots rather than encoded graph archives.

    Read the full bite: Outline the key steps and APIs for State Preservation and Restoration

16. Question 16 of 30

    What is the primary reason to choose UICollectionView over UITableView for displaying data?

    • aTo easily handle user interactions such as item selection and reordering.
    • bTo enable complex, non-linear layouts like grids, stacks, or custom arrangements.
    • cTo efficiently display a long, scrollable list of uniform text items.
    • dTo reduce memory usage when displaying a large number of items.
    Show the answer

    Answer: b · To enable complex, non-linear layouts like grids, stacks, or custom arrangements.

    The card emphasizes UICollectionView's purpose is to manage and display data in "highly complex, non-linear, and dynamic arrangements" such as grids or stacks, which UITableView cannot easily achieve. While both are efficient and handle interactions, only UICollectionView offers this advanced layout flexibility as its primary distinguishing feature.

    Read the full bite: UICollectionView: Grids, Stacks, and Custom Layouts

17. Question 17 of 30

    A modally presented view controller needs to report both Save and Cancel actions back to its parent. Which approach best balances decoupling and memory safety?

    • aStore a strong reference to a delegate protocol so callbacks are guaranteed to fire, and use a single closure with an optional Bool parameter to distinguish events.
    • bPost Save and Cancel notifications through NotificationCenter to avoid direct references between the child and parent.
    • cDefine a weak delegate protocol with separate methods for each event, letting any conforming parent handle them without knowing its concrete type.
    • dInject two closures—one for save and one for cancel—and capture self strongly to prevent premature deallocation.
    Show the answer

    Answer: c · Define a weak delegate protocol with separate methods for each event, letting any conforming parent handle them without knowing its concrete type.

    A weak delegate protocol with multiple methods keeps the child decoupled from any specific parent and avoids retain cycles, which is ideal for several distinct actions. Option D is tempting but dangerous because strong self captures create a retain cycle: the child holds the closure and the closure holds the parent.

    Read the full bite: Pass data back from a modally presented view controller delegate versus closure

18. Question 18 of 30

    What is the primary role of UIHostingController in iOS development?

    • aTo enable the integration of SwiftUI views within an existing UIKit-based application.
    • bTo manage the lifecycle of UIKit view controllers when embedded within a pure SwiftUI application.
    • cTo convert existing UIKit views into SwiftUI views for a complete application rewrite.
    • dTo optimize the rendering performance of complex SwiftUI views by leveraging UIKit's core graphics.
    Show the answer

    Answer: a · To enable the integration of SwiftUI views within an existing UIKit-based application.

    UIHostingController is designed to bridge SwiftUI content into UIKit apps, allowing for incremental adoption of SwiftUI. It does not convert UIKit views, nor is it used for embedding UIKit in pure SwiftUI, and it can introduce performance overhead rather than optimize rendering.

    Read the full bite: UIHostingController: Bridge SwiftUI into UIKit Apps

19. Question 19 of 30

    What is the fundamental principle governing how an event propagates through the Responder Chain?

    • aThe event is directly sent to the UIWindow object, which then dispatches it to the appropriate view.
    • bThe event travels from the most specific UI element upwards through its superviews and controllers until handled.
    • cThe event is handled by the first responder, and if not, it is immediately discarded by the system.
    • dThe event is broadcast simultaneously to all eligible responder objects in the application.
    Show the answer

    Answer: b · The event travels from the most specific UI element upwards through its superviews and controllers until handled.

    The card states that an event 'starts at the most specific object (the view that was tapped) and travels "up" a pre-defined path of potential responders.' Option B accurately describes this upward propagation. Option C is incorrect because events are not discarded if the first responder declines; they continue up the chain.

    Read the full bite: The Responder Chain: Who Handles That Tap?

20. Question 20 of 30

    In a scene-based iOS app, which sequence correctly handles a deep link to an order detail for both cold and warm launches?

    • aHandle cold starts in willConnectTo and warm launches in openURLContexts; parse path components with URLComponents and validate the ID before pushing.
    • bRoute the URL via AppDelegate's application(_:open:options:) and broadcast a notification for SceneDelegate to push the detail view controller.
    • cIntercept every URL in openURLContexts because it fires for both cold starts and warm launches once the scene is connected.
    • dHandle all URLs in willConnectTo, extract the order ID by splitting the URL string, and force-unwrap the root view controller to push.
    Show the answer

    Answer: a · Handle cold starts in willConnectTo and warm launches in openURLContexts; parse path components with URLComponents and validate the ID before pushing.

    Cold-start URLs arrive in willConnectTo through connectionOptions.urlContexts, while warm launches use openURLContexts, and URLComponents safely parses the path before validating the ID and pushing. The distractor that funnels everything through willConnectTo misses the warm-launch entry point, relies on brittle string splitting, and risks a crash by force-unwrapping the view hierarchy.

    Read the full bite: Handle a deep link URL in SceneDelegate and navigate to order detail.

21. Question 21 of 30

    Which scenario best justifies using UIViewRepresentable in a SwiftUI application?

    • aTo integrate a third-party SDK component that is only provided as a UIKit UIView.
    • bTo convert an entire legacy UIKit application into a SwiftUI application in a single step.
    • cTo simplify the implementation of common UI elements like buttons and text fields in SwiftUI.
    • dTo create highly performant custom drawing views that SwiftUI's native shapes cannot handle.
    Show the answer

    Answer: a · To integrate a third-party SDK component that is only provided as a UIKit UIView.

    UIViewRepresentable's primary purpose is to bridge existing, complex UIKit components into SwiftUI, especially when SwiftUI lacks a native equivalent or for third-party SDKs. Using it for simple views (Option C) is explicitly discouraged, and while it aids migration, it's not a single-step conversion of an entire app (Option B). While UIKit can be used for custom drawing, the card emphasizes leveraging *existing* complex components rather than creating new ones because SwiftUI's shapes are insufficient (Option D).

    Read the full bite: UIViewRepresentable: Bridging UIKit and SwiftUI

22. Question 22 of 30

    Which architecture best decouples auth state from the view hierarchy while ensuring smooth transitions and no memory leaks?

    • aPush the UITabBarController onto the onboarding UINavigationController stack after login and pop it on logout.
    • bUse an app coordinator to swap the window rootViewController on auth changes, crossfade with a snapshot, and nil the outgoing stack.
    • cKeep both onboarding and authenticated container hierarchies in memory, toggling hidden state when the user logs in or out.
    • dPresent onboarding as a full-screen modal over the main UITabBarController so the authenticated flow remains alive underneath.
    Show the answer

    Answer: b · Use an app coordinator to swap the window rootViewController on auth changes, crossfade with a snapshot, and nil the outgoing stack.

    A dedicated coordinator that swaps the window root and releases the old hierarchy prevents retain cycles and keeps auth logic out of the app delegate. Presenting onboarding modally over the tab bar (D) tightly couples the two flows and forces the main interface to know about authentication state.

    Read the full bite: How would you architect the app root for onboarding vs authenticated flows?

23. Question 23 of 30

    Which task is most appropriate for the AppDelegate according to its intended purpose?

    • aHandling network requests to fetch data from a remote server.
    • bPerforming complex data validation for user input forms.
    • cInitializing global services like analytics and crash reporting at app launch.
    • dManaging the display logic for a specific user interface screen.
    Show the answer

    Answer: c · Initializing global services like analytics and crash reporting at app launch.

    The AppDelegate is designed for global, lifecycle-tied tasks such as initializing core services like analytics at launch. Other options like managing UI display, data validation, or network requests are considered business logic that should be delegated to specialized objects, not the AppDelegate, to avoid bloating it.

    Read the full bite: The AppDelegate: Your App's Central Command

24. Question 24 of 30

    Which approach correctly separates navigation from presentation in a unit-testable conditional wizard for both UIKit and SwiftUI?

    • aEmbed branching logic directly in the view body and view controller lifecycle methods, wrapping a UINavigationController for use in SwiftUI.
    • bUse a UIKit coordinator but manage the SwiftUI stack with local @State variables mutated inside onAppear handlers.
    • cModel the flow as a state machine enum with plain Swift transition logic and derive the UIKit and SwiftUI stacks from that state.
    • dStore the current step in a view model and use NavigationLink isActive booleans in SwiftUI while calling pushViewController from UIKit button actions.
    Show the answer

    Answer: c · Model the flow as a state machine enum with plain Swift transition logic and derive the UIKit and SwiftUI stacks from that state.

    Modeling the wizard as a state machine enum with plain Swift transition logic lets you derive the stack for both UIKit and SwiftUI and unit test transitions without launching a UI. Option B is tempting because coordinators correctly separate UIKit concerns, but relying on local @State inside onAppear handlers still buries imperative navigation inside the view rather than driving it declaratively from the model.

    Read the full bite: Design state-driven navigation for a conditional wizard in UIKit and SwiftUI

25. Question 25 of 30

    In iOS 13 and later, what is the fundamental role of UISceneDelegate in an application's architecture?

    • aTo handle the lifecycle and state changes for a single UI instance, such as a window or scene.
    • bTo provide a centralized mechanism for managing user authentication and authorization flows.
    • cTo facilitate communication between different app extensions and the main application target.
    • dTo manage the entire application's process lifecycle, including background tasks and memory warnings.
    Show the answer

    Answer: a · To handle the lifecycle and state changes for a single UI instance, such as a window or scene.

    The card states UISceneDelegate is the "lifecycle manager for a single window of your app's UI" and was created "to manage a single UI instance." Option D describes the role of AppDelegate for the overall app process, not UISceneDelegate.

    Read the full bite: UISceneDelegate: Managing Your App's UI Instances

26. Question 26 of 30

    What is a fundamental characteristic of iOS State Preservation?

    • aIt is primarily used to restore the user's navigation path and view hierarchy after app termination.
    • bIt requires the app to remain in the background to function, not for terminated states.
    • cIt automatically persists all critical user data across app launches.
    • dIt replaces the need for other persistence mechanisms like Core Data or UserDefaults.
    Show the answer

    Answer: a · It is primarily used to restore the user's navigation path and view hierarchy after app termination.

    State preservation is designed to restore the UI's navigation path and view hierarchy after an app has been terminated by the system. It is explicitly stated that it is not for saving critical user data, which is the role of other persistence mechanisms.

    Read the full bite: iOS State Preservation: Resume Where You Left Off

27. Question 27 of 30

    For which navigation pattern is UINavigationController primarily designed?

    • aSwitching between distinct, top-level app sections.
    • bGuiding users through a hierarchical, drill-down sequence of screens.
    • cPresenting temporary, overlaid content like a login form.
    • dAllowing users to swipe horizontally between sibling content views.
    Show the answer

    Answer: b · Guiding users through a hierarchical, drill-down sequence of screens.

    UINavigationController is designed for hierarchical, 'drill-down' navigation, managing a stack of screens from general to specific. Options A and B describe use cases for UITabBarController and modal presentations, which the card explicitly advises against for this controller.

    Read the full bite: UINavigationController: Stack-Based Screen Management

28. Question 28 of 30

    For which scenario is a UITabBarController the most appropriate choice?

    • aGuiding a user through a multi-step account creation wizard.
    • bAllowing users to switch between an app's main, independent sections like "Feed" and "Profile."
    • cPresenting a temporary pop-up view for user confirmation.
    • dNavigating from a list of search results to a detailed product page.
    Show the answer

    Answer: b · Allowing users to switch between an app's main, independent sections like "Feed" and "Profile."

    A UITabBarController is designed for top-level navigation between distinct, non-sequential sections of an app, as described in option B. Options A and B describe sequential or hierarchical navigation, which are better suited for a UINavigationController, while option C is a modal presentation, not a primary navigation pattern.

    Read the full bite: UITabBarController: Your App's Main Switchboard

29. Question 29 of 30

    When using a Storyboard Segue, how is data typically passed from the source view controller to the destination view controller?

    • aBy implementing the prepare(for:sender:) method in the source view controller to configure the destination.
    • bBy using a global singleton object to store and retrieve data accessible by both view controllers.
    • cBy directly assigning data to properties of the destination view controller instance within the source view controller's action method.
    • dBy embedding the data directly into the segue object's properties before it performs the transition.
    Show the answer

    Answer: a · By implementing the prepare(for:sender:) method in the source view controller to configure the destination.

    The card explicitly states, "To pass data, you implement the prepare(for:sender:) method in the source view controller." This method is called just before the transition, allowing the source to configure the destination view controller. Other options describe alternative data passing patterns or incorrect understandings of segue mechanics.

    Read the full bite: Storyboard Segues: Visual UI Flow in iOS

30. Question 30 of 30

    You set cornerRadius and masksToBounds = true on a view, then add a shadow, but no shadow appears. What is the cause?

    • aShadows require the view to be added to a UIStackView
    • bcornerRadius and shadowRadius cannot both be non-zero
    • cmasksToBounds clips the layer's content to its bounds, including the shadow
    • dshadowOpacity is read-only on a clipped layer
    Show the answer

    Answer: c · masksToBounds clips the layer's content to its bounds, including the shadow

    masksToBounds true clips everything to the bounds, so the shadow drawn outside is removed. The usual fix is a separate container for the shadow or an explicit shadowPath, not toggling shadowOpacity.

    Read the full bite: Add shadow and rounded corners to a UIView