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 / 10 completed
1 / 10
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 / 10
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 / 10
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 / 10
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 / 10
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.
6 / 10
Alex: 'I've just finished implementing the new user onboarding flow. It uses Firebase for authentication and analytics. Can you review this PR and let me know if you have any concerns?'
Which of the following responses best addresses Alex's request?
The best response acknowledges Alex's positive choice (Firebase) but highlights the crucial missing element: a discussion of data privacy and compliance. Simply stating 'Excellent' is insufficient as it doesn't prompt further investigation into potentially important areas like GDPR or user consent. Option A focuses solely on a lack of description, ignoring the technical choices themselves.
7 / 10
Sarah (Slack message): 'The app is crashing intermittently when users upload large images. I've added logging to track the upload process, but haven't found a clear pattern.'
Which approach would be most effective for Sarah to take next?
Sarah's situation requires detailed diagnostics. Crash reporting services provide invaluable data – stack traces pinpointing the exact line of code causing the crash, along with device and OS information. While retries are a good strategy, they address network errors, not the underlying cause of the crash. Requesting another developer to review her logging is unlikely to resolve the issue if the logging itself isn't correctly configured.
8 / 10
API Response:
```json
{
"status": "error",
"code": 400,
"message": "Invalid request parameters: 'userId' must be a positive integer."
}
```
Which of the following statements best explains how this response should influence the developer's actions?
This API response clearly indicates a client-side error – an invalid input. The developer's primary responsibility is to correct their own code before sending requests to the server. Reporting the issue immediately might be appropriate if it's a widespread problem, but the first step is always validating the data being sent.
9 / 10
David (Standup Update): 'I'm working on integrating with the new payment gateway. I've set up the API calls and am currently testing transaction processing.'
Which follow-up question would be most appropriate for your team lead to ask David?
While David's update covers the basic steps, it lacks critical details regarding security. Payment gateway integrations are inherently sensitive, and ensuring proper security measures are in place is paramount. The other options – error rates, time estimates, and UI design – are relevant but secondary to immediate security considerations.
10 / 10
You're tasked with optimizing a list of 500 items displayed in a mobile app. Which approach would be MOST effective for improving performance?
Sorting the list is a fundamental optimization technique. When users scroll, only the items currently visible on screen need to be rendered. Lazy loading (option 1) is effective for large datasets but requires careful implementation to avoid performance issues with frequent data retrieval. Reducing view complexity (option 3) can improve rendering speed, and increasing threads (option 4) may not always provide significant benefits due to limitations like the Global Interpreter Lock in some environments.
What does "Mobile Developer Interview Questions — IT English Practice" cover?
Practice answering mobile developer interview questions in English: iOS lifecycle, offline handling, React Native vs Flutter, push notifications, and list performance. 5 exercises.
How many questions are in this interview set?
This set has 10 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.