Lazy loading

Performance Junior Swift 5.0+ iOS 17+ Reviewed By Alok Singh

Pick the fix

A SwiftUI screen shows 10,000 rows and takes seconds to appear. Fix?

Options
Hint 1 of 1

Which containers build rows on demand?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Use List, or a LazyVStack inside a ScrollView, so rows are created as they appear

Correct. Only visible rows are built.

Why not the others?
  • B Wrap the VStack in a ScrollView. A plain VStack still builds every row up front.
  • C Use an HStack instead. It's just as eager, in the other direction.
  • D Add .id(UUID()) to each row. New ids every render make it slower.

30-second answer

Lazy loading defers work until it is needed: lazy var properties are created on first access, lazy stacks and lists build rows as they scroll into view, images load when cells appear, and pagination fetches pages as the user nears the end. It lowers launch time, memory and network use.

Practise saying it · 30 s. No recording, just a timer

Explain lazy loading.

Say your answer out loud, then check which of these points you covered:

  • Defer until needed
  • Lazy views and pagination
  • Thread-safety caveat

Deep dive

lazy var isn't thread-safe; first access from two threads can initialise twice.

SwiftUI's List and LazyVStack create rows on demand.

Trigger the next page a few items before the end.

Lazy initialise heavy SDKs after the first frame.

Common mistakes

  • VStack with thousands of rows.
  • Lazy properties accessed from several threads.

Senior take & follow-ups

Seniors apply lazy loading at every layer: properties, views, data and SDKs.

Follow-up questions

Think of your answer first, then open the hint.

  1. Is lazy var thread-safe?

    Show hint

    No.

  2. When do you load the next page?

    Show hint

    When an item near the end appears.

Suggest a fix if something here is wrong or out of date.