Walk me through how you would optimise iOS app cold-start time.

Performance is the senior Mobile Engineer differentiator. Strong candidates start by asking what the current cold-start is, what the target is, and which iOS versions matter. They then walk through the ladder: defer non-essential framework loading (lazy load), reduce dynamic library count, defer heavy work past first frame using async tasks, optimise main bundle size, profile with Instruments App Launch template, and verify on real low-end devices. Mention that Apple's measured launch time and perceived launch time are different. Weak candidates jump to 'lazy loading'. The kill-shot is recommending caching alone or never having profiled with Instruments. UK panels at consumer apps test cold-start specifically; it correlates with retention.

How do you handle offline-first architecture in a mobile app?

Architecture instinct. Strong answers cover: local-first data store (SQLite/Core Data on iOS, Room on Android), sync engine with conflict resolution strategy (last-writer-wins is rarely sufficient — describe a CRDT or operational-transform approach for collaborative data), background sync respecting battery and network, optimistic UI updates with rollback, and clear indicators of sync state to the user. Mention specific UK-relevant constraints (rural 4G, London Tube no-signal). Weak candidates describe 'we cache the API response'. The kill-shot is not having a conflict-resolution story. UK consumer-app panels at Bumble/Just Eat/Monzo test offline-first as a standard senior interview topic.

Tell me how you approach state management in a SwiftUI or Compose app.

Reactive UI state is where senior mobile is won. Strong SwiftUI answers describe ObservableObject + @Published for ViewModel state, @State for view-local, @StateObject for owned dependencies, @EnvironmentObject for shared app state, with TCA or similar architecture for complex flows. Strong Compose answers describe StateFlow + ViewModel + collectAsStateWithLifecycle, unidirectional data flow, and immutable state classes. Mention the testability advantage of unidirectional data flow. Weak candidates describe MVC or never having moved past UIKit/View patterns. The kill-shot is not knowing the difference between @State and @StateObject (or for Android, between LiveData and StateFlow). UK senior mobile panels expect this fluency.

Walk me through how you would test a mobile app at production scale.

Test strategy reveals seniority. Strong answers cover the test pyramid for mobile: unit tests for business logic and ViewModel, integration tests for repository + data layer, UI tests for critical user flows (XCUITest on iOS, Compose Test or Espresso on Android), snapshot tests for design-system components, accessibility tests with the platform tooling, and beta channels for real-device testing (TestFlight, Play Console internal track). Mention CI/CD with simulator/emulator farm for fast feedback and real-device testing for critical paths. Weak candidates describe 'we have unit tests'. The kill-shot is not knowing what snapshot testing is or never having shipped via TestFlight/Play.

How do you handle accessibility on mobile?

Accessibility on mobile is now a UK shortlist filter, especially in regulated sectors. Strong iOS answers cover: VoiceOver labels and traits, Dynamic Type for text scaling, Sufficient contrast, reduce-motion respect, accessibility audit with Accessibility Inspector and real VoiceOver testing. Strong Android answers cover: TalkBack labels and content descriptions, Material accessibility guidance, font-scale respect, contrast checking, accessibility scanner. Mention that you test with the screen reader on at least once per release. Weak candidates list APIs without testing. The kill-shot is admitting you have never used VoiceOver/TalkBack on a real device. UK regulated-sector panels disqualify on this question alone.

Tell me about a time you debugged a hard production bug from crash logs.

Behavioural with technical depth. Strong answers describe a specific bug, the symptom (crash rate, user reports, ANR rate), the investigation (Crashlytics or App Store Connect crash logs, dSYM symbolication, ProGuard mapping for Android, distributed tracing if available), the hypothesis testing, the fix, and the rollout (phased release, kill-switch readiness). Mention specific tools and what crash signatures looked like. Weak answers describe debugging with print statements or never having shipped a fix to a real production crash. The kill-shot is having no production crash story at senior level. UK panels expect at least one shipped-mobile-fix war story by mid-senior.

How do you handle release management — phased rollout, monitoring, and rollback?

Operations question. Strong answers cover: feature-flagged release with the ability to disable a feature without app-store review, App Store phased release (iOS) or Staged Rollouts (Play), monitoring crash rate / ANR rate / key metric (DAU, conversion) per cohort, kill-switch on the server side for high-risk features, and rollback procedure (cannot recall an iOS app from store, can pause Play rollout). Mention that you would not ship a feature without a feature flag. Weak candidates describe 'submit to store, hope'. The kill-shot is having no kill-switch strategy. UK fintech and consumer-app panels test release discipline directly.

How do you approach battery and network efficiency?

Mobile-specific concern that filters senior from junior. Strong answers cover: avoid frequent wake-ups (batch network requests, use silent push instead of polling), respect Doze and App Standby on Android, BGTaskScheduler on iOS for background tasks, JobScheduler/WorkManager on Android, image compression and adaptive quality, prefetch only what is needed, and measure energy impact in Xcode Energy gauge or Android Studio Profiler. Mention WiFi-only fallbacks for large downloads. Weak candidates describe 'we use cached responses'. The kill-shot is not knowing what Doze mode is. UK panels at consumer apps test battery efficiency because it correlates with user retention.

Walk me through how you would build an in-app messaging or chat feature.

Feature-design question that exposes architecture skill. Strong answers cover: real-time delivery (WebSocket or specific protocols like XMPP for chat-heavy apps), local message store with offline-first sync, message-state machine (sent/delivered/read), media handling (lazy load, thumbnails, full-resolution on demand), typing indicators with throttle, push notification fallback for delivery when app backgrounded, and end-to-end encryption if required. Mention scaling considerations (room sharding, presence). Weak candidates describe a polling-based chat. The kill-shot is recommending REST polling for chat in 2026. UK consumer and B2B-mobile panels test this scenario specifically.

Tell me about a time you cut app size or build time meaningfully.

Behavioural with technical depth. Strong answers are specific: 'iOS app was 220MB and grew 8 percent quarter-on-quarter; Android Bundle was 45MB. I audited assets, replaced lossless PNGs with WebP/HEIC where supported, removed 4 unused frameworks, switched localisation from full-locale to on-demand, and migrated from XCFrameworks to SPM with whole-module optimization. Final iOS install size 80MB, Android Bundle 18MB. Build time on CI dropped from 14 minutes to 4 minutes through better module boundaries and parallel build.' Weak answers describe no specifics. The kill-shot is having no story; UK senior mobile hires are expected to have at least one real size-or-build-time war story.

How do you handle App Store / Play Store review and the unwritten rules?

Practical question that distinguishes engineers who have shipped from engineers who have only built. Strong answers cover: avoid private API usage (auto-rejection on iOS), respect IAP rules (Apple's 30 percent / Apple's reduced commission edge cases, Reader app rules), Play Console policy on permissions and data declarations, Privacy Manifest on iOS 17+, Data Safety form on Play, common rejection reasons (broken app, misleading metadata, inadequate privacy policy), and that responding to review rejection professionally with evidence often wins. Weak candidates describe submission as a one-shot. The kill-shot is admitting you have never dealt with a review rejection. UK senior mobile hires have shipped real apps; the question filters for that.

Why are you leaving your current role?

Standard closer. Strong answers are forward-looking: you want bigger user-volume to learn from, you want a 2026-current stack (SwiftUI/Compose first if your current is UIKit/Views first), you want to lead the mobile platform engineering function, you want a regulated-fintech challenge if your current is consumer or vice versa. Weak answers attack your current employer or describe burnout. The kill-shot is criticising the iOS/Android lead by name. UK mobile is a small community in London especially; everyone interviewing you knows the engineer you are complaining about. Stay forward-looking. The panel wants reassurance you will not be making the same complaint about them in 18 months.

Interview Q's · Tech · UK 2026

Mobile Engineer Interview Questions UK

Mobile Engineer interviews in UK 2026 are weighted toward platform depth (iOS Swift/SwiftUI or Android Kotlin/Jetpack Compose, sometimes both for senior cross-platform roles), performance discipline (cold-start, frame rate, memory), offline-first architecture, and shipped App Store / Play Store experience at real download volumes. Senior Mobile Engineers in London earn £85-120k base, more at fintech and consumer apps with traction. The 12 questions below are the ones I see in real UK loops at Bumble, Just Eat, Monzo, Revolut and consumer-AI scale-ups. I have written each answer from the recruiter's side: what the panel is testing for, what a strong response looks like, and what mistake immediately ends the conversation.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Walk me through how you would optimise iOS app cold-start time.

Performance is the senior Mobile Engineer differentiator. Strong candidates start by asking what the current cold-start is, what the target is, and which iOS versions matter. They then walk through the ladder: defer non-essential framework loading (lazy load), reduce dynamic library count, defer heavy work past first frame using async tasks, optimise main bundle size, profile with Instruments App Launch template, and verify on real low-end devices. Mention that Apple's measured launch time and perceived launch time are different. Weak candidates jump to 'lazy loading'. The kill-shot is recommending caching alone or never having profiled with Instruments. UK panels at consumer apps test cold-start specifically; it correlates with retention.
Question 2

How do you handle offline-first architecture in a mobile app?

Architecture instinct. Strong answers cover: local-first data store (SQLite/Core Data on iOS, Room on Android), sync engine with conflict resolution strategy (last-writer-wins is rarely sufficient — describe a CRDT or operational-transform approach for collaborative data), background sync respecting battery and network, optimistic UI updates with rollback, and clear indicators of sync state to the user. Mention specific UK-relevant constraints (rural 4G, London Tube no-signal). Weak candidates describe 'we cache the API response'. The kill-shot is not having a conflict-resolution story. UK consumer-app panels at Bumble/Just Eat/Monzo test offline-first as a standard senior interview topic.
Question 3

Tell me how you approach state management in a SwiftUI or Compose app.

Reactive UI state is where senior mobile is won. Strong SwiftUI answers describe ObservableObject + @Published for ViewModel state, @State for view-local, @StateObject for owned dependencies, @EnvironmentObject for shared app state, with TCA or similar architecture for complex flows. Strong Compose answers describe StateFlow + ViewModel + collectAsStateWithLifecycle, unidirectional data flow, and immutable state classes. Mention the testability advantage of unidirectional data flow. Weak candidates describe MVC or never having moved past UIKit/View patterns. The kill-shot is not knowing the difference between @State and @StateObject (or for Android, between LiveData and StateFlow). UK senior mobile panels expect this fluency.
Question 4

Walk me through how you would test a mobile app at production scale.

Test strategy reveals seniority. Strong answers cover the test pyramid for mobile: unit tests for business logic and ViewModel, integration tests for repository + data layer, UI tests for critical user flows (XCUITest on iOS, Compose Test or Espresso on Android), snapshot tests for design-system components, accessibility tests with the platform tooling, and beta channels for real-device testing (TestFlight, Play Console internal track). Mention CI/CD with simulator/emulator farm for fast feedback and real-device testing for critical paths. Weak candidates describe 'we have unit tests'. The kill-shot is not knowing what snapshot testing is or never having shipped via TestFlight/Play.
Question 5

How do you handle accessibility on mobile?

Accessibility on mobile is now a UK shortlist filter, especially in regulated sectors. Strong iOS answers cover: VoiceOver labels and traits, Dynamic Type for text scaling, Sufficient contrast, reduce-motion respect, accessibility audit with Accessibility Inspector and real VoiceOver testing. Strong Android answers cover: TalkBack labels and content descriptions, Material accessibility guidance, font-scale respect, contrast checking, accessibility scanner. Mention that you test with the screen reader on at least once per release. Weak candidates list APIs without testing. The kill-shot is admitting you have never used VoiceOver/TalkBack on a real device. UK regulated-sector panels disqualify on this question alone.
Question 6

Tell me about a time you debugged a hard production bug from crash logs.

Behavioural with technical depth. Strong answers describe a specific bug, the symptom (crash rate, user reports, ANR rate), the investigation (Crashlytics or App Store Connect crash logs, dSYM symbolication, ProGuard mapping for Android, distributed tracing if available), the hypothesis testing, the fix, and the rollout (phased release, kill-switch readiness). Mention specific tools and what crash signatures looked like. Weak answers describe debugging with print statements or never having shipped a fix to a real production crash. The kill-shot is having no production crash story at senior level. UK panels expect at least one shipped-mobile-fix war story by mid-senior.
Question 7

How do you handle release management — phased rollout, monitoring, and rollback?

Operations question. Strong answers cover: feature-flagged release with the ability to disable a feature without app-store review, App Store phased release (iOS) or Staged Rollouts (Play), monitoring crash rate / ANR rate / key metric (DAU, conversion) per cohort, kill-switch on the server side for high-risk features, and rollback procedure (cannot recall an iOS app from store, can pause Play rollout). Mention that you would not ship a feature without a feature flag. Weak candidates describe 'submit to store, hope'. The kill-shot is having no kill-switch strategy. UK fintech and consumer-app panels test release discipline directly.
Question 8

How do you approach battery and network efficiency?

Mobile-specific concern that filters senior from junior. Strong answers cover: avoid frequent wake-ups (batch network requests, use silent push instead of polling), respect Doze and App Standby on Android, BGTaskScheduler on iOS for background tasks, JobScheduler/WorkManager on Android, image compression and adaptive quality, prefetch only what is needed, and measure energy impact in Xcode Energy gauge or Android Studio Profiler. Mention WiFi-only fallbacks for large downloads. Weak candidates describe 'we use cached responses'. The kill-shot is not knowing what Doze mode is. UK panels at consumer apps test battery efficiency because it correlates with user retention.
Question 9

Walk me through how you would build an in-app messaging or chat feature.

Feature-design question that exposes architecture skill. Strong answers cover: real-time delivery (WebSocket or specific protocols like XMPP for chat-heavy apps), local message store with offline-first sync, message-state machine (sent/delivered/read), media handling (lazy load, thumbnails, full-resolution on demand), typing indicators with throttle, push notification fallback for delivery when app backgrounded, and end-to-end encryption if required. Mention scaling considerations (room sharding, presence). Weak candidates describe a polling-based chat. The kill-shot is recommending REST polling for chat in 2026. UK consumer and B2B-mobile panels test this scenario specifically.
Question 10

Tell me about a time you cut app size or build time meaningfully.

Behavioural with technical depth. Strong answers are specific: 'iOS app was 220MB and grew 8 percent quarter-on-quarter; Android Bundle was 45MB. I audited assets, replaced lossless PNGs with WebP/HEIC where supported, removed 4 unused frameworks, switched localisation from full-locale to on-demand, and migrated from XCFrameworks to SPM with whole-module optimization. Final iOS install size 80MB, Android Bundle 18MB. Build time on CI dropped from 14 minutes to 4 minutes through better module boundaries and parallel build.' Weak answers describe no specifics. The kill-shot is having no story; UK senior mobile hires are expected to have at least one real size-or-build-time war story.
Question 11

How do you handle App Store / Play Store review and the unwritten rules?

Practical question that distinguishes engineers who have shipped from engineers who have only built. Strong answers cover: avoid private API usage (auto-rejection on iOS), respect IAP rules (Apple's 30 percent / Apple's reduced commission edge cases, Reader app rules), Play Console policy on permissions and data declarations, Privacy Manifest on iOS 17+, Data Safety form on Play, common rejection reasons (broken app, misleading metadata, inadequate privacy policy), and that responding to review rejection professionally with evidence often wins. Weak candidates describe submission as a one-shot. The kill-shot is admitting you have never dealt with a review rejection. UK senior mobile hires have shipped real apps; the question filters for that.
Question 12

Why are you leaving your current role?

Standard closer. Strong answers are forward-looking: you want bigger user-volume to learn from, you want a 2026-current stack (SwiftUI/Compose first if your current is UIKit/Views first), you want to lead the mobile platform engineering function, you want a regulated-fintech challenge if your current is consumer or vice versa. Weak answers attack your current employer or describe burnout. The kill-shot is criticising the iOS/Android lead by name. UK mobile is a small community in London especially; everyone interviewing you knows the engineer you are complaining about. Stay forward-looking. The panel wants reassurance you will not be making the same complaint about them in 18 months.

How to use these answers

Mobile Engineer interviews in UK 2026 reward platform depth (iOS Swift/SwiftUI or Android Kotlin/Compose, with senior cross-platform fluency increasingly valued), performance discipline, accessibility judgement and shipped App-Store-and-Play-Store experience. The single biggest mistake I see is candidates with personal-project mobile experience trying to interview at consumer-app or fintech scale; the depth required for production mobile at scale is significantly different. Prep with three real shipped features you can talk through end-to-end (the architecture, the platform constraints, the performance numbers, the rollout story). Practise system-design rounds on mobile-specific problems (offline-first sync, real-time chat, video pipeline). UK senior mobile hires get the salary premium because they earn it on platform depth, performance instinct and operational discipline as much as Swift/Kotlin fluency.

Related across UK Rights & Guides

Keep reading

JobLabs UK 215+ guide directory →

Pillars + free tools

Related job-search guides + calculators

Pillars

→ UK Career Change handbook — sector-switch playbook
→ UK CV foundations guide — CV format + ATS-safe AI prompts
→ UK Interview Prep — UK process pillar — STAR + 4-stage UK process
→ UK Cover Letter writing reference 2026 — five UK opening patterns

Free recruiter-built tools