Mobile developer screening questions: iOS, Android, cross-platform and the apps you can check
On this page
- Native iOS, native Android or cross-platform: place the candidate
- Check the shipped apps before the call
- What they built inside the app
- Releases, store review and rollouts
- Crashes, performance and devices
- Platform features that show depth
- How mobile resumes overstate the work
- Logistics, knockout checklist and scorecard
- Questions people ask
Mobile developer screening questions should establish three things: which platform the candidate really works in, which apps they shipped and which parts were theirs, and whether they have owned a release from build to store to crash report. The advantage you have over most technical screens is that mobile work is public. You can open the store listing before the call, read the release notes and update dates, and ask the candidate to connect their story to what you saw.
The general engineering screen, including the ownership ladder and stack checks, is in software engineer phone screen questions. This page adds what is specific to mobile: native versus cross-platform, the store check, app review and staged rollouts, crash and device quality, and the ways mobile resumes overstate.
Native iOS, native Android or cross-platform: place the candidate
Clients usually hire for one of these, and a resume that says "mobile developer" can mean any of them. The languages and tools give it away quickly.
| Platform | Languages and tools you should hear | Ask | Common mismatch |
|---|---|---|---|
| Native iOS | Swift, SwiftUI or UIKit, Xcode; Objective-C in older codebases | "Is your current app mostly SwiftUI or UIKit, and why?" | Cross-platform developer who has only opened Xcode to build |
| Native Android | Kotlin, Jetpack Compose or XML layouts, Android Studio, Gradle; Java in older codebases | "What did you migrate from Java or XML layouts, and what broke?" | Web developer with one Android side project |
| React Native | TypeScript or JavaScript, plus native modules in Swift or Kotlin when needed | "When did you last have to write or fix native code, and what was it?" | Never touched the native layer, for a role that needs it |
| Flutter | Dart, platform channels for native features | "Which platform-specific problem took you longest to solve?" | Only shipped to one platform despite a cross-platform framework |
| Kotlin Multiplatform | Shared Kotlin logic, native user interfaces on each side | "What was shared, and what stayed native?" | Shared code on a demo project only |
Ask "What percentage of your last year was iOS, Android or shared code?" The answer is often more honest than the skills section, and it tells you whether the candidate fits a native role on one platform or a team that needs someone who moves between both.
Check the shipped apps before the call
This takes five minutes per candidate and changes the quality of the screen. Search each app the resume names in the App Store and Google Play, and fill in a worksheet like this one.
Store check — [candidate name], [role]
App name: [ ]
Store link(s): iOS [ ] Android [ ]
Publisher on the listing: [company / agency / candidate]
Still available? [yes / removed / region-limited]
Last update date: [ ]
Release notes mention: [features the candidate claims, if any]
Ratings and recent reviews: [anything about crashes, speed, a feature they built]
Candidate's tenure there: [dates from resume]
Questions this raises:
1. [e.g. "Release notes show the new checkout in March. Was that yours?"]
2. [e.g. "Android version updated last week; iOS not in a year. Why?"]What the check tells you, and what it does not:
- The publisher will usually be the company. Store listings name the business that published the app, not the developer. The test is whether the candidate's story fits the listing.
- Dates matter. If the resume says they rebuilt onboarding in 2025 and the release notes show a new onboarding that year, that supports the claim. If the app has not been updated since before they joined, ask what they shipped.
- Removed apps are not automatically a problem. Startups close and apps get pulled. Ask what happened and whether they have screenshots or a recording of their own work.
- Some work is never public. Internal enterprise apps, white-label apps built by agencies and apps distributed privately to one company will not show up. Ask the candidate to describe the users and the distribution method instead.
What they built inside the app
"Built the Acme app, 2 million users" can mean the candidate wrote the whole thing or the settings screen. Ask for the feature, not the app.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| Which screens or features in that app would you point to as yours? | Names them: "The offline cart, the checkout flow and the push notification settings." | "All of it," from someone on a team of fifteen. |
| How many mobile developers were on the app, and how was work split? | A number and a split by feature or platform. | Does not know who else worked on it. |
| How did the app get its data, and what happened with no signal? | Describes the API calls, caching and what the user saw offline. | Never considered offline use in an app used on the move. |
| Tell me about a feature that behaved differently on iOS and Android. | A specific difference: permissions, background work, notifications, keyboard behavior. | "They're the same," from someone who claims both. |
| What did you change after users started using your feature? | A change driven by reviews, analytics or support tickets. | No idea how the feature was received. |
Releases, store review and rollouts
Mobile releases are slower and less reversible than web releases. A bad web deploy can be rolled back in minutes; a bad app version stays on phones until users update. Developers who have owned releases talk about this without being asked.
- "Who submitted builds to the stores, and have you done it yourself?" Strong: has uploaded builds, managed signing certificates and provisioning profiles on iOS or signing keys on Android, and has a story about one of them expiring or going missing. Red flag: "the lead did that" for a senior role.
- "Tell me about an App Store or Google Play rejection." Strong: the reason given, what they changed and how long it delayed the release. Red flag: has never had one, after several years of shipping.
- "How did you roll out a new version?" Strong: a gradual rollout. Apple offers a phased release of updates over a 7-day period to users with automatic updates on, per Apple's App Store Connect help, and Google Play supports staged rollouts to a percentage of users that the team increases over time, per Play Console Help (both as of September 2026). Red flag: every release went to everyone at once, with no way to stop it.
- "How did you handle users stuck on an old version?" Strong: minimum supported versions, a forced-update prompt, or keeping the API backward compatible. Red flag: never thought about it.
- "How often did you ship, and how were builds made?" Strong: a cadence (every two weeks, for example) and the build tooling, such as Xcode Cloud, Fastlane, Bitrise or GitHub Actions. Red flag: builds made by hand on one person's laptop, described as normal.
- "How did testers get builds before release?" Strong: TestFlight on iOS, internal or closed testing tracks on Google Play. Red flag: no pre-release testing at all.
Crashes, performance and devices
Quality on mobile has numbers attached, and Google Play publishes some of them. As of September 2026, Google says an app is in its bad-behavior zone when at least 1.09 percent of daily active users experience a user-perceived crash across all devices, or at least 8 percent on a single device model, and that crossing those thresholds can make the app less discoverable, per Android Developers. You do not need the candidate to quote those figures. You need to know whether they watched a crash rate at all.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| How did you know the app was crashing, and what was the crash rate? | Names the tool (Firebase Crashlytics, Sentry, Android vitals, Xcode Organizer) and a rough figure or trend. | Found out from app store reviews. |
| Tell me about the worst crash you fixed. | A specific cause: a device model, an OS update, a memory problem, a race condition, and how they reproduced it. | Cannot describe one. |
| Which OS versions and devices did you support, and who decided? | A minimum version, the reason, and a device they had to test on specially. | "All of them." |
| What did you do to make the app faster or smaller? | A measured change: startup time, scrolling, image loading, app size, with a before and after. | "Optimized performance," no numbers. |
| How did you test with VoiceOver or TalkBack? | Has done it and fixed something it found. | Never heard of either, for a consumer app. |
Platform features that show depth
Pick the two or three the client's app depends on. You are listening for a story from real work, not a definition.
| If the role needs | Ask | Strong answer | Red flag |
|---|---|---|---|
| Push notifications | "What went wrong the first time you set up notifications?" | Something about tokens, permissions, Apple Push Notification service or Firebase Cloud Messaging setup. | Only used a vendor dashboard to send them. |
| In-app purchases or subscriptions | "How did you check a purchase was real?" | Receipt or purchase validation on a server, and a story about refunds or restores. | Trusted whatever the device reported. |
| Offline and sync | "What happened when two devices changed the same record offline?" | A conflict rule they chose and why. | Has not met the problem in a role that needs it. |
| Privacy and permissions | "How did you decide when to ask for location or tracking permission?" | Asked at the moment of need, with a reason shown; knows the store privacy disclosures had to match. | Asked for everything at first launch. |
| Architecture | "How was state managed, and what would you change?" | Names the approach and a limitation they hit. | Only built screens inside a structure someone else chose, described as "architected the app." |
How mobile resumes overstate the work
| Pattern | What it looks like | How to check |
|---|---|---|
| App count | "Published 14 apps" | Open them. Tutorial clones and template apps with no updates are common in junior portfolios. |
| Both platforms | "iOS and Android developer" | "How much Swift or Kotlin did you write last year?" Often the answer is cross-platform code only. |
| App users as personal scale | "App with 2M users" | "Which features were yours?" |
| Agency blur | Six client apps in two years | "How long were you on each, and what was live when you left?" |
| Release by proxy | "Owned releases" | "When did you last upload a build and manage signing?" |
| Old credential as current | Associate Android Developer listed prominently | Google says the exam has been retired and existing credentials stay valid until they expire, per Google for Developers (as of September 2026). Check the date; weigh shipped work more. |
For senior roles, a technical exercise run by the client's engineers is normal. If the client uses a take-home, the guidance in how to evaluate a take-home assignment applies, and QA-heavy mobile roles overlap with QA engineer phone screen questions.
Logistics, knockout checklist and scorecard
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| For contract roles: do you have your own Mac and test devices, or do you need them supplied? | A clear answer. iOS builds need a Mac; agree who provides it before the start date. See IT contractor screening questions for terms. | Assumes the client will ship hardware with no one having agreed it. |
| Releases go out every two weeks, sometimes with an evening check after rollout. Does that work? | A clear yes or a limit. Ask about the schedule, not family circumstances. | Surprised that releases need any follow-up. |
| What salary or rate do you need? | A number or range. Ask expectations, not current pay; see salary expectation questions. | Only a salary-site figure. |
| Are you legally authorized to work in the US, and will you now or in the future need visa sponsorship? | A direct answer to both. | None. Ask everyone the same two questions. |
Must-ask on every mobile developer screen
- Platform split: native iOS, native Android, cross-platform, and the percentage of each.
- The store check, and one question it raised.
- Features that were theirs in a named app, and team size.
- Release ownership: builds, signing, review, rollout.
- A crash they fixed and how they measured crashes.
- One platform feature the client's app depends on.
- Hardware (for contractors), release schedule, salary or rate, notice, other processes, work authorization.
Knock out, or flag to the client before submitting, if:
- The role is native and the candidate has written little or no Swift or Kotlin themselves.
- No app they name can be found, and they cannot describe their own work in a way that fits a private or removed app.
- A senior role owns releases and the candidate has never shipped a build to a store.
- They offer a previous employer's source code or internal builds as proof.
| Area | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Platform depth | Tutorials or one side project | Features in shared or cross-platform code | Native features on the target platform | Native depth plus platform-specific problem solving |
| Shipped work | Nothing checkable | App found, own part unclear | Named features that match the listing | Several releases with outcomes they measured |
| Release ownership | Never involved | Watched releases | Submitted builds, handled review | Ran staged rollouts and handled a bad release |
| Quality | No crash data | Knew crashes existed | Fixed crashes with a tool and a number | Improved crash rate or performance with a baseline |
| Logistics fit | Deal-breaker | Two open questions | One open question | All aligned |
Put the store link and the feature the candidate named side by side in your notes: "built the offline cart (in the March release notes); 'we cut checkout crashes after the iOS 18 update'" is something a mobile lead can check in a minute. Interview Signal attaches quotes like that to each score from the call, so your worksheet and the candidate's own words end up in one place.
Questions people ask
Can a React Native or Flutter developer fill a native iOS or Android role?
Sometimes, but not by default. Cross-platform developers who have written native modules, handled code signing and debugged platform-specific crashes can move across; those who have only worked in the shared code usually need time. Ask what they have written in Swift or Kotlin themselves.
How do I check a mobile developer's apps if they were published under the employer's name?
Ask for the store link and the features they built, then look for those features in the listing's release notes and update dates. Store listings name the company, not the individual developer, so the check is whether their story matches the listing, not whether their name appears.
Are there certifications that matter for mobile developers?
Very few carry weight. As of September 2026, Google says its Associate Android Developer exam has been retired, though existing holders keep the credential until it expires. Shipped apps, release history and a technical exercise tell a client far more.
Should I ask a candidate to show me an app they built for a previous employer?
You can ask them to walk you through the public version of it, as any user could. Do not ask for source code, internal builds or anything covered by their confidentiality obligations; a candidate who offers those anyway is showing you how they would treat your client's code.