When you hit a system design interview for an iOS role, the interviewer isn't just checking if you know how to call an API. They want to see if you can anticipate how an app behaves when it's actually in the hands of a million users on varying network speeds. A classic prompt is "Design a social media feed." If you start by saying, "I'll make a network call to get the posts and display them in a list," you've already lost the "Senior" designation. That's the naive approach, and in a production environment, it's a recipe for a sluggish UI and a frustrated user base.

The "Fetch All" Trap and the Memory Wall

The most common mistake I see is treating the mobile client like a browser page that just refreshes. The naive approach is to have a FeedViewModel that calls GET /posts, receives a giant JSON array of 500 posts, and maps them directly to a List or UITableView. On a fast office Wi-Fi connection with a brand new iPhone 15, this feels fine. But imagine a user on a spotty 4G connection in a subway. They'll stare at a loading spinner for ten seconds, and then the app might just crash because you've tried to allocate too much memory at once to hold a massive array of high-res image URLs and metadata.

Beyond the memory pressure, you're wasting the user's data plan. Why download 500 posts when the user is only going to scroll through the first ten? This approach lacks scalability and fails to account for the "infinite" nature of social media.

Pagination and the Local Cache Layer

To fix this, we need to shift our thinking from "fetching data" to "managing a stream." I always recommend implementing cursor-based pagination. Instead of asking for "Page 2," which can lead to duplicate items if a new post is added to the top of the feed while the user is scrolling, we ask for "posts created before this specific ID."

But pagination alone isn't enough for a premium feel. If the user closes the app and re-opens it, they shouldn't see a loading spinner again. This is where you introduce a local persistence layer—something like SwiftData or CoreData. The flow changes to this: the UI observes a local database, and the network layer silently updates that database in the background. When the user opens the app, they see the cached posts immediately. The app then fetches new content, merges it into the local store, and the UI updates reactively. I've found that this "Offline First" architecture is what separates a junior dev from an engineer who understands the mobile lifecycle.

Optimistic Updates vs. The Loading Spinner

Now, let's talk about interaction, specifically the "Like" button. The naive way is to hit the "Like" button, show a UIActivityIndicator, wait for the server to return a 200 OK, and then change the heart icon to red. It feels clunky. It makes the app feel like it's tethered to a slow server.

The better way is an "Optimistic Update." You update the UI to the "liked" state immediately, as if the server has already agreed. Simultaneously, you fire off the network request. If the request succeeds, great—the user never noticed a delay. If it fails, you gracefully roll back the state and show a small toast notification saying "Couldn't save like." This trade-off—accepting a tiny risk of a state rollback in exchange for perceived instantaneous speed—is exactly what users expect from apps like Instagram or X.

// A simplified look at the Optimistic Update pattern
func toggleLike(postId: String) async {
    let previousState = self.posts[postId].isLiked
    
    // 1. Optimistic Update: Change UI immediately
    self.posts[postId].isLiked.toggle()
    
    do {
        try await networkService.likePost(id: postId)
        // Success! No further action needed.
    } catch {
        // 2. Rollback: Something went wrong, revert to previous state
        self.posts[postId].isLiked = previousState
        self.errorMessage = "Failed to like post. Please try again."
    }
}

📋 Practical Task

Implement an Optimistic Like System

Create a small Swift prototype of a FeedViewModel that manages a list of Post objects. Each Post should have an id, content, and isLiked boolean.

• Implement a toggleLike(postId:) function using the async/await pattern.
• Create a mock NetworkService that randomly fails (throws an error) 30% of the time to simulate poor network conditions.
• Ensure that the isLiked state of the post updates instantly in the ViewModel, but reverts to its original state if the NetworkService throws an error.
• Print the state of the post to the console before the network call, after the call succeeds, and after a rollback occurs to verify the timing of the updates.