Mobile Developer Interview Questions 2026

Last updated: September 13, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

Good mobile developer interview questions in 2026 ask about a store release the candidate owned, an app that survived process death and a dead network, and the exact point where their framework ran out. Trivia predicts nothing. A candidate can define a TurboModule, a composable, and a Swift actor in one breath and still freeze the first time a build sits in App Review for six days with a launch date on the calendar.

Most of the trouble starts on the req.

“Mobile developer” is three jobs wearing one LinkedIn title. Native iOS. Native Android. And cross-platform, which is really two more jobs, because a React Native engineer and a Flutter engineer share almost nothing once you get below the screen layer. A loop written for “mobile” in general ends up quizzing a blend of all of them, and a blended quiz rewards whoever studied the most flashcards.

Last spring a company in Carlsbad that makes the companion app for a golf launch monitor hired a React Native engineer through four rounds. A JavaScript screen, a hooks exercise, a system design conversation about a leaderboard service, and a culture interview. He was good at all four. Genuinely good. Six weeks after he started, the team moved to React Native 0.82, and the Bluetooth library that talked to their hardware had never been ported to the New Architecture. No maintainer. No fork anyone trusted.

The app couldn’t find the device.

Nobody on that team had written Objective-C++ or Kotlin in two years, and it turned out the new hire hadn’t ever written either one, so the roadmap sat for five weeks while they paid a contractor $140 an hour to build the native module the loop never asked about. Ten minutes of questioning would have surfaced it.

Full disclosure on incentives, since a staffing company is about to tell you how to interview. KORE1 has placed engineers since 2005, our mobile developer staffing team sits within the IT staffing services side of the company, and we get paid when a client hires somebody we introduced. A few recommendations below make searches shorter. One suggests the native work might belong to an engineer you already employ. None of that helps our invoice. It stays in.

Which Mobile Developer Are You Actually Interviewing?

On intake calls for mobile searches, the most common first sentence from a client is some version of “we need someone who can do both.” Sometimes that’s right. More often it means the platform decision hasn’t been made yet, and the interview loop quietly inherits the ambiguity. Then it tests for everything.

Write down where the hire will spend 70 percent of their week. Then pick the row.

If two rows describe the job, you may have two hires. Or one hire and a contractor. If the seat is Android and nothing else, our Android developer interview questions go much deeper on Compose and coroutines than this page will. What follows is the material that applies across every stack, plus the screen that cross-platform candidates need and almost never get.

Five Questions Every Mobile Candidate Should Get

Stack doesn’t matter for these. A Swift engineer, a Kotlin engineer, and a Flutter engineer should all have real answers, and the shape of a weak answer is the same in every language.

The OS kills your app mid-checkout while it’s in the background. Ten minutes later the user taps the icon. What do they see?

Process death. Every mobile platform does it, and demo apps never experience it, which is why this question splits people so cleanly.

A weak answer says the app reopens where they left off. It doesn’t, unless somebody wrote the code that makes it. Strong candidates talk about what state gets persisted and when, and they separate the cart (which lives on a server and can be refetched) from the half-typed address field (which lives nowhere unless the app saved it). On Android they’ll mention testing it with adb shell am kill or the “Don’t keep activities” developer setting. Flutter engineers who’ve actually shipped know that RestorationMixin exists and that almost nobody uses it. Fair enough. React Native engineers should say, without being led, that the JavaScript bundle restarts cold and navigation state is gone unless they persisted it themselves.

Then ask how they’d know it was happening to real users. Silence is common. Good.

A field technician edits a work order in a basement with no signal. Meanwhile a dispatcher changes the same order on the web. What happens when the technician walks back upstairs?

There isn’t a right answer. There’s a right first move, and it’s a question back to you about what kind of data the work order is.

Last-write-wins is a product decision, not a default, and an engineer who treats it as the obvious answer has probably never watched a customer lose a signature. We have. It’s ugly. Better candidates ask whether fields can merge independently, whether the server keeps version numbers, and whether the user should see a conflict at all. The ones who’ve really been burned describe a sync queue that survived an app update, because that’s the nasty case, a queued write sitting in local storage while the schema it was written against changes underneath it.

Which test device do you own that you would never buy for yourself?

Short question. Revealing.

Engineers who care about real users name something specific and slightly embarrassing, a budget Samsung Galaxy A-series phone, a first-generation iPhone SE with the small screen, a tablet some field sales team still carries. Engineers who don’t care say they test in the simulator and on their own phone, which is a flagship bought within the last year. Firebase Test Lab or a device farm in CI is a fine answer too, as long as they can tell you what the farm caught that they would have missed.

The user tapped “Don’t Allow” on notifications. Now what?

Plenty of apps simply stop working the way the product team designed after that tap, and nobody notices for a quarter. Revenue notices first. Strong answers cover asking at a moment of obvious value instead of on first launch, provisional authorization on iOS for quiet delivery, the POST_NOTIFICATIONS runtime permission Android added in version 13, and a denial path that still lets the user finish what they came to do. Watch for anyone who suggests re-prompting on every launch. That person has never read their one-star reviews.

Tell me about a bug that only showed up in the release build.

Every experienced mobile engineer has one. Debug builds are forgiving and release builds are not, and the gap between them is where years of experience actually live.

R8 stripping a class that was only ever reached through reflection. A Swift optimization that exposed a race the debug build had been hiding for months. Hermes bytecode doing something the Chrome debugger never showed anyone, or a week of crash reports nobody could read because the dSYMs never got uploaded. Any of those is a real answer. A candidate with no release-only bug either hasn’t shipped much or hasn’t been the person paged when it broke, and both of those are worth knowing before round two.

Who Owned the Last Release?

Titles lie. Release history doesn’t.

Apple moved the floor again this year. Since April 28, 2026, App Store Connect only accepts apps built with Xcode 26 and the iOS 26 SDK, which meant every iOS team with an update in the pipeline had to recompile against a new SDK on Apple’s schedule rather than their own. Standard controls picked up the new Liquid Glass look on recompile whether design had signed off or not. The deployment target could stay put. Plenty of teams still lost a sprint. Some lost two. Ask a senior iOS candidate what changed in their app on that recompile, and whether they found out before or after QA did.

Google’s version of the same pressure landed earlier. Starting November 1, 2025, new apps and updates targeting Android 15 or higher had to support 16 KB memory page sizes to get through Play Console. Apps written purely in Kotlin or Java were fine by default. Apps carrying native libraries were not, and React Native and Flutter both ship native libraries, as do a lot of the SDKs teams bolt on for payments, document scanning, and analytics.

A property-management company in Sacramento found that out in November. Their Flutter app’s update was blocked because a document-scanning plugin bundled a .so file compiled against an old NDK. Eleven days to fix. The engineer they’d hired in September had scored perfectly on a Dart quiz and had never opened the android folder in the project, which is not a knock on him, just a description of what the loop had checked for.

Three release questions do most of the work for a senior seat.

• Who holds the signing keys, where do they live, and what happens the week that person resigns? Listen for Play App Signing, App Store Connect API keys stored in CI rather than on somebody’s laptop, and an actual plan.
• Walk me through a rollback. This one is a trap, gently. Neither store will pull an update back off a phone that already installed it, so the honest answer involves pausing a phased release or halting a staged rollout, then shipping forward, ideally behind a remote kill switch that existed before anything went wrong.
• What did your last release checklist leave out? Nobody’s is complete, and the candidate who can name the gap owned the list.

React Native and Flutter Candidates Need Their Own Screen

The Carlsbad problem is not rare. It’s the default outcome when a cross-platform engineer gets interviewed like a web engineer.

React Native 0.82, released in October 2025, runs entirely on the New Architecture, and the old flag for turning it off now does nothing. Any app upgrading past that line needs every native dependency to work with TurboModules and Fabric. Most popular libraries made the jump. The long tail of hardware, payments, and media libraries that small companies depend on did not, and somebody on the team has to either port those or replace them. Ask who did that work at the candidate’s last job. If the answer is “another team,” ask what they learned from watching. Usually plenty.

For React Native, three questions carry the screen. What does the native code in your most recent project do, and who wrote it? Did you use Expo’s prebuild workflow or maintain the ios and android folders by hand, and what did that choice cost you later? When did the JavaScript thread become your bottleneck, and how did you prove it?

Flutter is different in the details and identical in spirit. It draws its own pixels, so candidates rarely fight native UI components the way React Native engineers do, but they fight the boundary everywhere else. Ask what code runs on the platform side of their channels and how they found out when it was blocking. Ask whether they used Pigeon for type-safe messages or wrote the serialization themselves, and why. Ask about a plugin they had to patch. A Flutter engineer with three strong years and a patched plugin is a better senior hire than one with five years who has never needed to open Xcode, and I’d make that trade every time.

One uncomfortable suggestion here. If you already employ a capable iOS or Android engineer, the native module work may belong to that person, with the cross-platform hire owning the shared code. That’s a smaller req. Sometimes it’s no req at all. We’ve told two clients that this year, and one of them listened. When a search does make sense, our React Native developer staffing and Flutter developer staffing desks screen for exactly this boundary.

iOS Questions That Still Catch Strong Candidates

Two are enough.

First, did your team turn on the Swift 6 language mode, and what did the compiler make you fix? Swift 6 turned data-race checking from a suggestion into a compile error. Anyone who migrated a real codebase remembers @MainActor creeping outward file by file, a pile of Sendable complaints on types nobody believed were shared, and at least one singleton that turned out to be touched from three threads. There’s always one. Candidates who say they’re “waiting for things to settle” are describing a team that hasn’t done it, which is common and fine, as long as your codebase hasn’t done it either.

Second, what’s in your app’s privacy manifest, and which third-party SDK forced you to add something to it? Apple has required privacy manifests and declared reasons for certain APIs since 2024. Senior iOS engineers remember which analytics or ads SDK held up their submission. Mid-level engineers often don’t know the file exists, because somebody else handled it. For the rest of the iOS picture, including where that talent pool is thin, the 2026 iOS hiring guide covers the sourcing side.

The Exercise: Turn Off the Network

Skip the take-home. Run this instead, live, for about an hour.

Give the candidate a small sample app in their stack with two screens, a list and a detail view with an editable form, plus a save that syncs to a mock server. Let them read the code for fifteen minutes and ask questions. Then start breaking things while they watch. Throttle the connection to something awful using the Network Link Conditioner on a Mac or the emulator’s network settings. Kill the app halfway through a save. Rotate the device, or resize the window on a tablet. Toggle airplane mode while the list is loading.

You’re not grading whether they fix everything in an hour. Nobody does. You’re watching what they reach for, whether they add logging before guessing, whether they ask what the user should see when the save fails, and whether they notice the thing you didn’t break on purpose, because the sample app should have one small bug you planted and never mention. About half the strong candidates we’ve seen go through something like this find the planted bug without prompting. Almost none of the weak ones do.

It also works for React Native and Flutter candidates without modification, which a Swift-only whiteboard problem does not. Same hour. Same signal.

Rounds by Level, With 2026 Base Pay

Pair a senior-sized loop with a mid-level budget and the search stalls. Every time. Candidates who clear four rounds have options, and they take the option that pays what the loop implied.

Those ranges come from our 2026 mobile app developer salary guide, which breaks the numbers out by platform, industry, and metro. Native iOS still runs a few points above native Android at the senior level, and the Bay Area and Seattle sit well above these national figures. For a quick read on your own market before the req posts, the salary benchmark assistant takes a couple of minutes.

Speed matters as much as the band. Across KORE1’s IT desk, a typical search closes in 17 days. When a mobile search runs well past that, the cause is usually a fifth round that nobody on the hiring team could explain the purpose of when we asked. Cut that round. You will not miss it.

Questions From Teams Hiring Their First Mobile Engineer

We only have budget for one engineer. Native or cross-platform first?

Pick whichever platform most of your paying customers carry, and go native on it if the app touches cameras, Bluetooth, health data, or payments hardware. Cross-platform makes more sense for a first hire when the app is mainly screens of lists and forms talking to an API, and when shipping on both stores in the same week actually matters to the business.

Should a mobile loop include LeetCode-style algorithm problems?

Drop them for anyone below staff level. They measure interview preparation, and the mobile engineers with the most shipped work tend to have the least time to grind practice problems. The network exercise above takes the same hour and shows you how the person debugs an app, which is the job.

From first screen to signed offer, how long is reasonable?

Ten business days, start to finish. Longer than that and the candidates with other options accept one of them, which leaves you choosing among the people nobody else moved on. Not a great spot. A three-round loop fits comfortably inside two weeks if interviewers block their calendars before the req opens rather than after the first good resume arrives.

Nobody on our team has built a mobile app. Who sits on the panel?

Borrow a mobile engineer for the technical round. A contractor, a friendly engineer at a portfolio company, an advisor, even a paid hour from someone senior you trust. Backend engineers can judge API design and general reasoning well, but they will miss a weak answer about process death or App Review every single time, and those are the answers that predict the first six months.

Is a strong React web developer a reasonable bet for a React Native role?

For about half the job. Components, hooks, and state management transfer almost directly. Gestures, background execution, native modules, and store releases do not transfer at all. It can work well on a team that already has someone native to pair with, and it tends to go badly as a first and only mobile hire.

Contract-to-hire for a first mobile engineer, or straight to full-time?

Ninety days on contract usually tells you what a four-round loop only guesses at, because by then they have shipped a release or they haven’t. The catch is that the strongest senior mobile engineers often hold direct offers and won’t take a contract start. Our contract-to-hire staffing team writes the conversion terms down on day one, and engineers hired that way tend to stick, which is a big part of why 92% of our placements are still in the seat a year later.

Put an Old Phone on the Table

Cheapest improvement available.

Buy a used budget Android and an older iPhone, install your current build on both, and put them in front of the candidate at the start of the technical round. Ask them to use the app for five minutes and think out loud. People who have shipped start poking at things you never asked about. They rotate it. They pull down the notification shade mid-load, open the app switcher and swipe the app away, then relaunch to see what survived. People who haven’t shipped tap through the happy path and tell you it looks nice. It does look nice. That’s not the test.

Five minutes. Maybe $200 for both phones on a resale site, once.

If you’re still shaping the role itself, start with the mobile developer job description template, and our guide to hiring a mobile app developer walks through the platform decision in more depth than the table above. Our mobile developer recruiters cover over thirty U.S. metro areas, and they run iOS, Android, and cross-platform as separate searches instead of sending one pool for all three. When the slate keeps filling with people who interview beautifully and have never opened the native folder, talk with our mobile recruiting team and we’ll tell you plainly whether the gap is the req, the band, or the loop.