Build a chat screen in an existing iOS codebase

You are handed an existing iOS app you have never seen and asked to add an AI assistant chat screen to it: a scrolling list of messages, a field and Send button at the bottom, and replies from a backend. The round tests how quickly you find your way around unfamiliar code, how you prioritize, and whether you ship a working slice that fits the project's own patterns, compiling and running as you go.

Interface

Unless you agree on a different interface with the interviewer, assume:

• The app already has a networking layer, some screens and a navigation pattern (UIKit or SwiftUI, MVVM or similar). Reuse them; don't add a parallel architecture.
• A backend call along the lines of sendMessage(conversationId: String, text: String) async throws -> Message exists or is easy to add on the existing client.
• Message has an id, a role (user or assistant), text and a timestamp.

The screen must:

1. Show the conversation's messages in order, the newest at the bottom.
2. Send the typed text, show it at once, then show the reply when it arrives.
3. Show a pending state while waiting and an error with retry when a send fails.
4. Keep working when the keyboard opens and the list grows long.

Example

user types "Hello" and taps Send
  list: [you: "Hello" (sending…)]       field cleared, Send disabled while empty
reply arrives
  list: [you: "Hello", assistant: "Hi! How can I help?"]
network fails on the next send
  list: [..., you: "Another" (failed, tap to retry)]

Clarifying questions

• Which UI framework and architecture does the project use, and where do similar screens live?
• Does the backend stream replies, or return them whole?
• Is history loaded from the server, or only this session's messages?
• What matters most in the time we have: a polished UI, correct networking, or tests?

What a strong answer covers

• Spending the first minutes reading the project: the entry point, an existing screen to copy, the networking client and models.
• A thin working slice first (list, send, reply), then pending, error and retry states.
• An optimistic local message with a temporary id, replaced or marked failed when the call returns.
• Work off the main thread with UI updates on it; cancelling in-flight work when the screen closes.
• Keyboard avoidance and auto-scroll to the newest message; efficient cell reuse or a lazy list.
• Compiling and running often, and saying what you would add with more time (streaming, tests, accessibility).

Follow-ups

• The reply now streams token by token: what changes in the model and the cell?
• Persist the conversation offline and sync on reconnect.
• Two sends overlap and replies come back out of order. How do you keep the list right?
• How would you test this screen?