5 exercises — practice structuring strong English answers to real mobile interview questions: app lifecycle, offline-first architecture, cross-platform trade-offs, push notifications, and list performance.
How to structure mobile interview answers
Lifecycle questions: name the states → key callbacks → what to do in each → mention modern API (SceneDelegate)
Architecture questions: describe the layers → name the tools/frameworks → give the decision trade-offs
Comparison questions: explain the mechanism → practical implication → decision framework based on context
Performance questions: identify the mechanism (e.g., virtualisation) → name platform APIs → mention profiling tools
Show depth by naming specific APIs:UITableView, RecyclerView, APNs, NWPathMonitor, Core Data, Room
0 / 5 completed
1 / 5
The interviewer asks: "Can you explain the iOS app lifecycle and how your app should respond to lifecycle events?" Which answer is the most structured and complete?
Option B is the strongest: it names all five defined states in the correct order, uses modern API terminology (SceneDelegate, specific callback names), and ties each concept to a practical consequence (what you must do in each state). The structure — states → API callbacks → what to do — is exactly how senior mobile developers talk in interviews. Option A is too informal ("killed") and vague. Option C gets closer with specific method names but misses the state model and doesn't mention the newer SceneDelegate pattern. Option D defines the states but gives no concrete implementation guidance. When answering iOS lifecycle questions: state the five states → name the key callbacks → explain what tasks belong in each → mention the modern SceneDelegate pattern if relevant.
2 / 5
The interviewer asks: "How does your app handle offline state — when there's no network connection?" Which response best demonstrates architectural thinking?
Option C demonstrates offline-first architecture thinking that distinguished senior candidates. It describes three layers: cache (read), sync queue (write), connectivity monitoring (UX). This architecture means the app works fully offline — users can browse cached data and take actions, which sync automatically when connectivity returns. Key vocabulary used: Core Data (iOS) / Room (Android) — local SQLite-backed persistence frameworks. Sync queue — local queue of pending mutations, replayed on reconnect. NWPathMonitor (iOS) / ConnectivityManager (Android) — native APIs for monitoring network state. Option A is the minimum viable approach — only showing an error, no offline functionality. Option B is incorrect — URLSession's retry logic handles transient errors, not true offline state. Option D is a step better (uses Reachability) but disabling UI is not an offline-first strategy — it still leaves the user unable to work offline.
3 / 5
The interviewer asks: "What are the main differences between React Native and Flutter, and how would you choose between them?" Which answer best demonstrates technical depth and decision-making?
Option C is the strongest: it explains the fundamental architectural difference (bridge-to-native-widgets vs own rendering engine), the practical implication of each (platform-native feel vs pixel-perfect consistency), and gives a clear decision framework based on concrete factors. The key technical distinction for interviews: React Native renders native platform widgets — the same controls iOS and Android users are familiar with. Flutter renders its own widgets using its own graphics engine — they look the same on every platform but don't use native OS controls. Option A is too light — "whichever the team already knows" doesn't show architectural awareness. Option B is accurate but contains no differentiating insight. Option D is also technically solid but doesn't explain the rendering architecture clearly, which is the most interesting and differentiating piece for interviewers. Structure for comparison questions: explain the mechanism → state the practical implication → give a decision framework.
4 / 5
The interviewer asks: "How do push notifications work on iOS, and what do you need to handle on the app side?" Choose the most complete and accurate answer.
Option B is the strongest: it names the service (APNs), explains the full flow (app → APNs token → backend → APNs → device), and lists the specific Objective-C/Swift APIs showing real implementation experience. The complete flow for iOS push notifications: 1. App launches → calls registerForRemoteNotifications(). 2. iOS contacts APNs → receives a unique device token. 3. App sends token to your backend server. 4. Your server stores the token and calls the APNs API with a notification payload when needed. 5. APNs delivers to the device. App-side handling: UNUserNotificationCenter.requestAuthorization — request permission. didRegisterForRemoteNotificationsWithDeviceToken — receive token. didReceiveRemoteNotification — background content update. userNotificationCenter(_:willPresent:) — foreground display decisions. userNotificationCenter(_:didReceive:) — handle tap → deep link to correct screen. Android equivalent: FCM (Firebase Cloud Messaging) uses the same model with different APIs. Option D is partially correct (iOS maintains the APNs socket in the background) but incomplete and missing app-side responsibilities.
5 / 5
The interviewer asks: "How do you optimise the performance of a list with hundreds of items in a mobile app?" Which answer best demonstrates platform knowledge?
Option B demonstrates the deepest understanding of the underlying mechanism and platform-specific APIs. The key concepts: Virtualisation / cell reuse — the most important optimisation: only the visible cells exist in memory; as you scroll, old cells are recycled and populated with new data rather than creating new objects. iOS: UITableView.dequeueReusableCell(withIdentifier:for:). Android: RecyclerView with ViewHolder pattern. DiffUtil (Android) / diffing — instead of calling notifyDataSetChanged() (which redraws everything), calculate the minimal diff and animate only the changed items. prepareForReuse — cancel any in-flight image loads or tasks when a cell is about to be reused, preventing stale data. Fixed item height — prevents the layout system from measuring every item on every frame. Option A mentions pagination and async images — both correct, but misses the fundamental virtualisation mechanism. Option C describes lazy loading correctly but at a high level. Option D is a good answer (profiling first is the right instinct) but misses the virtualisation vocabulary that shows real platform expertise.