12 · Architect this screen, and tell me why

• Repository — the one owner of one kind of data. It turns the server's format into the app's model.
• Composite — a repository that only reads: it asks two repositories and combines their answers into one model.
• Store — in-memory state that several screens show at once. Here, the basket.
• Use case — one user intent with a product rule, like "only the latest tap counts".
• View model — the screen's brain. It owns the screen's state and hands the screen one view state.
• View state — one value that describes everything the screen shows. The view only draws it.
• MVVM, MV, TCA, VIPER — four ways to split a screen: view + view model · view on observable models · one reducer over state · five roles per screen.
• Composition root — the one place at launch that builds every part and hands each its collaborators.
• Router — the object that owns the navigation stack; screens ask it to go somewhere.
• Optimistic update — show the result of a tap at once, and correct it if the server refuses.
• Minor units — money as a whole number of the smallest coin, like 1999 cents.

"Walk me through the wireframe." → A hero photo, the name, rating ("4.6 · 1,200 reviews"), delivery time and fee. A heart in the top bar. Menu sections, each item with a photo, name, price and a ＋. A reviews summary: the average and the three latest. A pinned basket bar: "3 items · €24.50 · View basket".

"Where else does the basket show?" → On every store page, on the basket screen, and as a badge on the tab bar.

"Can a basket hold items from two stores?" → No. Adding from another store asks "Start a new basket?" first.

"Items with options?" → Tapping one opens an options sheet. That sheet is another screen; just navigate to it.

"Where do reviews come from?" → The store call returns the summary. The full list is another screen.

"Is the favourite shown anywhere else?" → A favourites list, which reloads when it opens.

"Offline, live updates?" → No. An error with retry is fine.

"Team and timeline?" → One team now, six feature teams within a year.

"Minimum OS?" → iOS 17, SwiftUI, Swift 6.

Out of scope, said first: the options sheet, the basket screen, checkout, search, the full reviews list, and the server. Photos come from question 1's image loader; requests go through question 9's HTTP client.

Required for the prompt

1. Show the store: header, menu sections, reviews summary.
2. Add an item to the basket, with the one-store rule, and keep the basket bar right.
3. Favourite and unfavourite the store, instantly, correctly under fast taps.

What must feel good: the ＋ answers at once · the bar, the badge and the basket screen always agree · prices are exact · the screen previews and tests without a network.

Production considerations (say, don't draw): accessibility, Dynamic Type, metrics, feature flags. See section 12.

Optional follow-ups (add only when asked):

More screens like this one      → the same template, a factory per screen
Six teams                       → a module per feature, routes not imports
Offline menus                   → a saved copy of the last store
Live stock or store closing     → push or polling, only if required

"I'll start simple and add each of these when the requirement appears."

"The screen is a dumb SwiftUI view over one main-actor view model that turns domain models into one view state. The store comes from a store repository, GET /stores/{id}, with the reviews summary and the favourite flag inside. The basket is shown on several screens, so it lives in one shared basket store, refreshed with GET /basket. Adding an item is a use case because it has a rule, one store per basket, and sends PUT /basket/items/{itemId}. Favouriting is a use case with Q2's like rule, latest tap wins, over PUT /stores/{id}/favourite. Everything is built once at a composition root and injected by constructor; a router owns navigation."

Nine cards, three chips. Store and Basket aren't cards; they open section 6.

Not drawn: AppRouter (protocol StoreNavigator), which owns the navigation stack, and Q1's image loader. Not on the list yet: a composite (the store call carries reviews and the heart), everything under "optional follow-ups".

flowchart TB
  subgraph P["PRESENTATION"]
    View["`**1 · Store screen**
StoreDetailView`"] -- "actions → view state" --> VM["`**2 · Store view model**
StoreDetailViewModel`"]
  end
  subgraph D["DOMAIN"]
    Add["`**3 · Add-to-basket use case**
SingleStoreAddToBasketUseCase
app-scoped, main actor`"]
    Fav["`**4 · Favourite use case**
SerialFavouriteUseCase
app-scoped actor`"]
    Bask["`**5 · Basket store**
BasketStore
bar, badge, basket screen`"]
    StoreP["`«protocol»
StoreRepository`"]
    BaskP["`«protocol»
BasketRepository`"]
    FavP["`«protocol»
FavouritesRepository`"]
  end
  subgraph DA["DATA"]
    StoreR["`**6 · Store repository**
RemoteStoreRepository
GET /stores/{id}`"]
    BaskR["`**7 · Basket repository**
RemoteBasketRepository
GET /basket
PUT /basket/items/{itemId}`"]
    FavR["`**8 · Favourites repository**
RemoteFavouritesRepository
PUT /stores/{id}/favourite`"]
  end
  HTTP["`**9 · HTTP client**
reused from Q9`"]
  VM -- "add → outcome" --> Add
  VM -- "read → basket" --> Bask
  VM -- "heart → outcome" --> Fav
  Add -- "apply → basket" --> Bask
  VM -- "load → store" --> StoreP
  Add -- "set → basket" --> BaskP
  Bask -- "refresh → basket" --> BaskP
  Fav -- "send → state" --> FavP
  Bask ~~~ StoreP
  Bask ~~~ FavP
  StoreP ~~~ StoreR
  StoreR -. "implements" .-> StoreP
  BaskP ~~~ BaskR
  BaskR -. "implements" .-> BaskP
  FavP ~~~ FavR
  FavR -. "implements" .-> FavP
  StoreR -- "endpoint → DTO" --> HTTP
  BaskR -- "endpoint → DTO" --> HTTP
  FavR -- "endpoint → DTO" --> HTTP
  class View,VM pres
  class Add,Fav,Bask,StoreP,BaskP,FavP dom
  class StoreR,BaskR,FavR data
  class HTTP reuse

How to read it. A solid arrow points from the asker to the answerer: request → reply. Dashed arrows mean implements; the grey card is question 9's networking layer.

Dependency inversion, in one line. The domain writes the three promises (the chips); the data layer keeps them, so every dashed arrow points up and nothing above the data frame knows HTTP exists.

A shared store belongs on this sketch: the basket is on three screens. The heart is on one at a time, so it stays in the view model.

One class, two promises. Both arrows meet the basket chip; each caller holds only its half: card 5 the read promise BasketReader, the use case the write promise BasketRepository. Card 7 keeps both.

On Miro: three frames, nine cards, three chips, twelve solid arrows. Point at card 5: "three screens, one basket. That's why it's a store and not view-model state."

The models everyone shares. Money is minor units plus a currency, never a Double.

struct Money: Hashable, Sendable {
    let minorUnits: Int
    /// ISO 4217, e.g. "EUR"
    let currency: String
}

struct Store: Identifiable, Sendable {
    let id: StoreID
    let name: String
    let hero: ImageRef
    let deliveryMinutes: ClosedRange<Int>
    let deliveryFee: Money
    let isOpen: Bool
    let isFavourite: Bool
    let menu: [MenuSection]
    /// average, count, the three latest
    let reviews: ReviewsSummary
}

struct Basket: Equatable, Sendable {
    /// nil = empty
    let storeID: StoreID?
    let lines: [BasketLine]
    /// Computed by the server: fees, promotions
    let total: Money
    /// Rises with every change on the server
    let version: Int
}

1 · Store screen (StoreDetailView)

Job: draws the view state and reports taps, appear and pull-to-refresh. It decides nothing.

Interface: reads viewModel.viewState; calls onAppear() from .task, refresh() from .refreshable, and the action methods.

Choice: a List with sections, so long menus reuse their rows.

2 · Store view model (StoreDetailViewModel)

Job: keeps this screen's state (load, pending heart, prompt) and turns the store and the basket into one view state.

struct StoreDetailViewState: Equatable {
    /// loading, loaded, failed(message)
    let load: LoadState
    /// name, "4.6 · 1,200 reviews", "25–35 min", "€1.99 delivery"
    let header: HeaderRow?
    /// filled, empty, or pending
    let heart: HeartState
    /// prices already formatted, "+" disabled while the store is closed
    let sections: [MenuSectionRow]
    let reviews: ReviewsRow?
    /// nil when the basket is empty
    let basketBar: BasketBar?
    /// "Start a new basket? Your items from {store} will be removed."
    let newBasketPrompt: Prompt?
}

@MainActor @Observable
final class StoreDetailViewModel {
    init(storeID: StoreID, stores: StoreRepository, basket: BasketStore,
         addToBasket: AddToBasketUseCase, favourite: SetFavouriteUseCase,
         navigator: StoreNavigator)

    var viewState: StoreDetailViewState { get }

    func onAppear() async
    func refresh() async
    /// Opens the options sheet instead, if the item has required options
    func add(_ item: MenuItemID) async
    func confirmNewBasket() async
    func toggleFavourite() async
    func openBasket()
}

Choices:

• viewState is computed from stored state and the basket store, so it never goes stale.
• Formatting happens here: minor units converted with the currency's exponent, then Decimal.FormatStyle.Currency.
• Navigation is asked, not done: navigator.showOptions(item), showBasket().

3 · Add-to-basket use case (SingleStoreAddToBasketUseCase)

Job: adds an item to the one shared basket, keeping the rule that a basket holds one store's items.

enum AddOutcome: Equatable, Sendable {
    case added
    /// The basket holds another store's items. Nothing changed.
    case needsNewBasket(currentStore: String)
    /// Refused or unreachable; the basket shows the server's state
    case failed(message: String)
}

protocol AddToBasketUseCase: Sendable {
    /// Never throws. Not cancelled by the caller's task: the write
    /// still lands, the caller only stops waiting.
    func add(_ item: MenuItemID, from store: StoreID,
             replacing: Bool) async -> AddOutcome
}

@MainActor
final class SingleStoreAddToBasketUseCase: AddToBasketUseCase {
    init(basket: BasketStore, repository: BasketRepository)
}

Choices:

• The rule a product manager would state: "one store per basket; ask before replacing". That's why adding is a use case and loading isn't.
• App-scoped and @MainActor, because it writes the main-actor store; one instance, so two screens can't send in parallel.
• Final quantities, one request per item ("quantity 3", never "+1"), Q2's rule. The server checks the one-store rule too: 409 other_store.

4 · Favourite use case (SerialFavouriteUseCase)

Job: sends the latest heart the user wants, one request per store at a time.

protocol SetFavouriteUseCase: Sendable {
    /// Never throws. Not cancelled by the caller's task.
    /// Returns saved, superseded or failed(serverState:), as Q2's like.
    func setFavourite(_ on: Bool, store: StoreID) async -> FavouriteOutcome
}

actor SerialFavouriteUseCase: SetFavouriteUseCase {
    init(favourites: FavouritesRepository)
}

Choice: question 2's like, reused. The pending heart lives in the view model, because only this screen shows it.

5 · Basket store (BasketStore)

Job: holds the one basket the bar, the badge and the basket screen all read, with pending quantities laid over it.

@MainActor @Observable
final class BasketStore {
    init(reader: BasketReader)

    /// The server's basket with pending quantities applied
    private(set) var basket: Basket
    var itemCount: Int { get }

    func refresh() async
    /// Ignored if its version is older than the one held
    func apply(_ basket: Basket)
    func setPending(_ quantity: Int, for item: MenuItemID)
    func clearPending(for item: MenuItemID)
}

Choices:

• The version is the stale-result guard: a reply older than what's held is dropped.
• No rules inside; the store only holds and applies.
• The total is the server's. While a change is pending, the bar dims it.

6 · Store repository (RemoteStoreRepository)

Job: fetches GET /stores/{id} and maps StoreDTO to Store, menu and reviews included.

protocol StoreRepository: Sendable {
    /// Throws on failure. Cancelling the caller cancels the request.
    func store(_ id: StoreID) async throws -> Store
}

Choice: reviews and the heart come inside the store call. Trade-off: separate endpoints would let two teams own them, at the cost of a second request and a composite, which nothing above would notice.

7 · Basket repository (RemoteBasketRepository)

Job: reads the basket with GET /basket and sets a quantity with PUT /basket/items/{itemId}. Two callers, two small promises.

/// Domain: the use case's promise
protocol BasketRepository: Sendable {
    /// Final quantity, 0 removes. replacing clears another store's
    /// basket first. Returns the server's basket. Throws
    /// BasketError.otherStore on 409. Cancelling the caller cancels
    /// the request; the use case runs it in its own task.
    func setQuantity(_ quantity: Int, of item: MenuItemID,
                     store: StoreID, replacing: Bool) async throws -> Basket
}

/// The store's promise
protocol BasketReader: Sendable {
    /// Throws on failure; the store keeps what it holds.
    func basket() async throws -> Basket
}

Choice: mapping and error codes stop here: the DTO's cents become Money, other_store becomes BasketError.otherStore.

8 · Favourites repository (RemoteFavouritesRepository)

Job: saves a heart with PUT /stores/{id}/favourite and returns what the server holds.

protocol FavouritesRepository: Sendable {
    /// Throws if refused or unreachable. Cancelling the caller
    /// cancels the request; the use case runs it in its own task.
    func setFavourite(_ on: Bool, store: StoreID) async throws -> Bool
}

Choice: a thin adapter; the heart is read with the store.

9 · HTTP client (reused from question 9)

Job: sends each endpoint and returns its DTO. Cards 6–8 see only its HTTPClient protocol.

Why these parts, and no more. Each card changes for one reason:

Each protocol earns a fake or a smaller promise. Not added: a use case for loading (a pass-through), a protocol for the view model, a composite, a DI container. Constructor injection is enough.

Flow 1 — opening the store page. The basket is already in the store, refreshed at launch.

sequenceDiagram
  participant V as Store screen
  participant VM as View model
  participant R as Store repo
  participant B as Basket store
  V->>VM: onAppear()
  VM->>R: store(id)
  alt loaded
    R-->>VM: Store
    VM->>B: read basket
    B-->>VM: 3 items, €24.50
    VM-->>V: header, menu, reviews, bar
  else failed
    R-->>VM: error
    VM-->>V: error with retry
  end

Flow 2 — adding from another store.

sequenceDiagram
  participant VM as View model
  participant U as Add use case
  participant B as Basket store
  participant R as Basket repo
  VM->>U: add(padThai, replacing: false)
  Note over U: basket holds another store
  U-->>VM: needsNewBasket("Corner Deli")
  Note over VM: shows the prompt, user confirms
  VM->>U: add(padThai, replacing: true)
  U->>B: setPending(1)
  U->>R: PUT /basket/items/padThai
  alt accepted
    R-->>U: basket v8
    U->>B: apply(v8)
    U-->>VM: added
  else refused
    R-->>U: error
    U->>B: clearPending, refresh
    U-->>VM: failed
  end

The bar, the badge and the basket screen change together: they read one store.

GET  /v1/stores/{id}
     → { "id", "name", "hero": { "url", "width", "height" },
         "deliveryMinutes": { "min": 25, "max": 35 },
         "deliveryFee": { "minorUnits": 199, "currency": "EUR" },
         "isOpen", "isFavourite",
         "menu": [ { "id", "title", "items": [ { "id", "name", "price",
                     "image", "hasRequiredOptions" } ] } ],
         "reviews": { "average": 4.6, "count": 1200, "latest": [ … ] } }

GET  /v1/basket
     → { "storeId", "version": 7, "lines": [ … ],
         "total": { "minorUnits": 2450, "currency": "EUR" } }

PUT  /v1/basket/items/{itemId}   { "storeId", "quantity": 1, "replacing": true }
     → 200 { …the basket, "version": 8 }
     → 409 { "error": { "code": "other_store" } }

PUT  /v1/stores/{id}/favourite   { "favourite": true }
     → 200 { "favourite": true }

• Money in minor units, the total computed by the server.
• Final quantities with PUT, idempotent, so the HTTP client may retry it.
• The store call is personal (isFavourite), never on a shared CDN; photos are.

"How would you structure the networking layer?" Point at card 9 and give question 9 in two lines: features describe requests as Endpoint values; one HTTPClient runs them through interceptors, one shared token refresh and retries for idempotent calls, and repositories map its errors to domain errors.

Decision: MVVM with @Observable: a dumb view, a main-actor view model, domain types below it. Then say what each alternative is good at.

1. Against MV (views read @Observable models and call repositories): less code, fine for a settings screen. But the prompt, the pending heart and the formatting land in the view, which can't be unit-tested. Switch for screens with no rules.
2. Against TCA (one reducer over state, effects as values): excellent for testing every state change. But it's a third-party dependency every team must learn, and it shapes the whole app. Switch if the team already uses it.
3. Against VIPER (five roles per screen): clear, but heavy and UIKit-era. Our use cases already play the interactor, only where there's a rule.
4. What MVVM buys here: the view state is a plain Equatable value, so tests assert on it and previews draw it.

The honest line: "The boundaries matter more than the pattern: rules out of views, I/O out of view models, shared state in one place. MVVM is the smallest pattern that does that here."

Rejected: a view model per row. Rows have no logic of their own.

More screens. Each is the same template: view, view model, view state, factory. The composition root builds shared parts once; a factory per screen builds its view model.

More teams. Six teams can't share one target.

1. A module per feature (Store, Basket, Checkout), each with its views, view models and repositories.
2. Shared domain in its own small module: Money, Basket, the repository protocols. Features depend on it, never on each other.
3. Navigation by route, not by import. Store calls navigator.showBasket(); the app module maps routes to screens with NavigationStack and navigationDestination(for:destination:). The Store module never imports Basket.
4. The app module is the composition root: the only place that knows every concrete type.

More state. A second screen showing the heart moves it into a favourites store, like the basket. The rule stays in the use case.

Rejected: a global @Environment bag of services. A missing value fails only at runtime, and dependencies vanish from the init. Environment is fine for values the view itself reads.

Decision: test the rules and the mapping, where bugs cost money; skip what the compiler or a preview already shows.

1. The use cases, with fake repositories: another store's basket returns needsNewBasket and sends nothing; three fast ＋ taps send one request, then the final quantity.
2. The view model, asserting on viewState with fakes and the real basket store: loaded, failed, closed (＋ disabled), €1.99 from 199 minor units, the prompt.
3. The basket store: a reply with an older version is ignored; pending quantities lay over the server's basket.
4. The repositories' mapping, with a fake HTTPClient returning a DTO: cents become Money, other_store becomes BasketError.otherStore.

All in Swift Testing, no network. Not unit-tested: the views; previews cover them.

Previews from the same fakes. #Preview builds the screen through a preview composition root with canned repositories: loaded, loading, failed, closed, a long name, the largest text, dark mode.

Rejected: UI tests for every state: slow and flaky. Two or three for the main path.

Failures

Production notes (short, not on the board)

• Networking: reads cancelled with the screen (.task does it); writes run in the use case's own task.
• Accessibility: the ＋ reads "Add Pad Thai, €9.50"; layouts survive the largest text size.
• Metrics and flags: time to first content, add failures, new-basket prompts shown versus confirmed; reviews behind a remote flag.

Scale, back of the envelope, with the interviewer's numbers:

store page views a day × size of one store payload   = bandwidth for this screen
adds a day × average taps per add                    = basket writes

A 150-item menu is about 60 KB of JSON; photos dominate, so they come from the image loader at the row's size. The architecture changes with teams, not traffic.

Grow only when asked

One screen shows the heart   → the pending heart in the view model
A second screen shows it     → a favourites store, like the basket
Reviews get their own team   → a second endpoint and a composite
Offline menus                → save the last store, show it first
Six teams                    → a module per feature, routes not imports

Answer out loud first, then open.

Architecture and the pattern

State and data

Basket and favourite

Navigation, DI and previews

Testing and scale

14+ is a pass.A zero names the thing to read about next.:::