Free iOS developer interview questions for small teams: 6 sets on Swift, App Store review, and handover, plus a scorecard and red flags. Download as DOCX.
Six question sets for the owner or manager running the interview: first-call screening, Swift and the Apple frameworks, App Store review and releases, architecture and testing, ownership and handover, and a scoring rubric. Every question says why it is worth asking and what a good answer sounds like. Download as DOCX.
The first time I sat across from an iOS developer with a hiring decision to make, I could not evaluate a single line of the code they were describing. What I could evaluate was whether the answers were specific, whether they were attached to an app I could actually download, and whether this person could explain a technical choice to me without making me feel stupid. Those three signals are available to any interviewer, and they turn out to predict the outcome better than the code review I could not run.
At FirstHR, we build for small businesses that hire without an HR department, where the owner runs the interview between everything else. This page gives you six question sets written for the employer side of the table. Every question states why it is worth asking and what a good answer sounds like, and the last set is a scorecard with an iOS-specific red-flag list.
TL;DR
Interview an iOS developer on five things: shipped apps you can install, Swift and framework depth (optionals, memory, concurrency, SwiftUI or UIKit), release ownership (signing, TestFlight, App Store review, crash response), architecture and testing, and handover. The best single screening question is what happens between finished code and the app being on your phone. Benchmark pay to software developers: a $135,980 national median (BLS OEWS, May 2025). Download six sets and a scorecard as DOCX.
What to Assess in an iOS Developer
Assess five areas: shipped iOS work you can verify, depth in Swift and the Apple frameworks, ownership of the release path through App Store review, architecture and testing decisions, and how the candidate works with a non-technical decision maker. A strong resume covers the first two. The last three are where small businesses get hurt.
The reason release ownership deserves its own set is structural. An iOS build cannot be pushed the way a website is pushed: it is signed, submitted, reviewed by Apple, and only then released to users. A developer who has written features on a large team may never have done any of that, because someone else owned it. That gap is invisible on a resume and expensive on your launch week.
Shipped iOS work
An app on the App Store you can install
A clear boundary between their work and the team’s
Honest account of internal or unreleased apps
Swift and framework depth
Optionals, memory, and concurrency explained plainly
A reasoned SwiftUI or UIKit position
A performance fix they actually measured
Release ownership
Signing, TestFlight, and submission owned end to end
Review time built into the schedule
A calm plan for a crash spike after release
Working with you
Explains technical choices without jargon
Raises slipping deadlines early
Accepts company ownership of accounts and code
Weight the areas to your situation. If this person will be your only mobile hire, release ownership and handover matter more than framework trivia, because you are buying continuity as much as code. If you already have engineers and are adding depth, you can lean harder on the technical set. Either way, ask the same core questions of every candidate so the comparison means something.
Which Question Set Should You Use?
Pick the sets that match the round you are running and the role you are filling. Most small businesses use the screening set on the first call, then two or three of the deeper sets in a second conversation, with the scorecard applied to every candidate at both stages.
First-Call Screening
30 minutes, any interviewer
Shipped apps you can install, the path from Xcode to the App Store, rejections, device support, and how they learn a release went wrong. Start here.
Swift and Frameworks
Technical round
Optionals and force-unwrapping, structs versus classes, retain cycles, concurrency, SwiftUI versus UIKit, on-device storage, and a measured performance fix.
App Store and Releases
The set most lists skip
Who owns the Apple account, signing and provisioning, TestFlight, review time, crash-spike response, and the privacy disclosures on your listing.
Architecture and Testing
Your year-two cost
How the app is structured, what gets tested and what deliberately does not, dependency restraint, accessibility, iPad support, and solo code review.
Ownership and Handover
Solo developer reality
What you would need if they left, disagreeing with a non-technical owner, thin requirements, estimates, early warnings, and whether they looked at your app.
Scorecard and Red Flags
Rate and protect
A six-area 1-to-5 rubric, an iOS-specific red-flag list, and a business-protection checklist covering the Apple account, signing keys, and code ownership.
Match the Set to the Round
First call with any candidate: Screening. Second round for a technical check: Swift and Frameworks plus Architecture and Testing. Your first or only mobile hire: add App Store and Releases, which is the set that protects the business. Contractor on a defined project: Ownership and Handover matters most, because the handover is the deliverable. Use the Scorecard with every set, every time.
6 Free Question Sets to Download
Download all six as a single Word document, or copy the sets you need. Each one follows the same shape: when to use it, the questions with a note on why each is worth asking and what a good answer sounds like, what to listen for, and space for notes. The last set is the rubric.
Download All 6 iOS Developer Question Sets
Screening, Swift and frameworks, App Store and releases, architecture and testing, ownership and handover, plus a scorecard with red flags. All in one DOCX.
Set 1: iOS Screening Questions (First Call)
Eight questions for a 30-minute first call that any interviewer can run: shipped apps, the path from Xcode to the App Store, rejections, device support, and how they find out a release went wrong.
iOS Screening Questions (First Call)
iOS DEVELOPER INTERVIEW: FIRST-CALL SCREENING
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO USE THIS SET
Run this as a 30-minute first call. You do not need to write Swift to use it.
Every question below is followed by what a good answer sounds like, so you can
tell a developer who has actually shipped an iOS app from one who has only
worked on pieces of somebody else’s. Ask all eight. Score at the end.
QUESTIONS
1. Name an app you shipped that I can download right now. What did you own on it?
(Why ask: shipping to the App Store is the whole job, and it is verifiable.
Good answer: a live listing, plus a clear boundary between their work and the
team’s. Internal or enterprise apps are fine if they explain the situation.)
2. Walk me through everything that happens between your code being finished and
the app being on my phone.
(Why ask: this single question separates a coder from an app owner. Good
answer: archive and sign the build in Xcode, upload to App Store Connect,
distribute through TestFlight, submit for review, then release, often phased.
Weak answer stops at "I push to the repository.")
3. Tell me about an App Store rejection you received. What was it, and what did
you do?
(Why ask: everyone who ships gets rejected. Good answer names the guideline,
describes the fix or the reply through the Resolution Center, and is matter of
fact. "That never happens to me" usually means they never submitted.)
4. Which iOS versions and devices would you support for a business like ours,
and why?
(Why ask: the deployment target is a business decision with a cost. Good
answer ties it to who our customers are, not to what is newest.)
5. What do you do every June when Apple announces the next iOS at WWDC?
(Why ask: iOS ships a major version every year and your app has to survive it.
Good answer: test on the betas over the summer, fix what breaks before the
September release, and plan any required changes.)
6. How do you find out that a release went badly?
(Why ask: you want someone who watches, not someone who waits for your call.
Good answer: crash reporting and analytics they check on purpose, plus
reviews. They should name the tools and the first hour of their response.)
7. What part of iOS development do you find hardest or least enjoyable?
(Why ask: honest self-assessment. Good answer is specific and human. "Nothing,
I love all of it" is a non-answer.)
8. What questions do you have about our product and our users?
(Why ask: the strongest candidates interview you. Good answer shows they read
what we do and are thinking about the actual app.)
WHAT TO LISTEN FOR
•A shipped app with a link, and a clear account of what they personally did
•Comfort with the whole path from Xcode to the App Store, not just the code
•Specifics over labels: named tools, named guidelines, named outcomes
•Curiosity about your users rather than only about your stack
NOTES
__
__
Set 2: Swift, SwiftUI, and UIKit Questions
The technical round: optionals and force-unwrapping, value versus reference types, retain cycles, concurrency and the main thread, the SwiftUI or UIKit decision, on-device storage, and a performance fix they measured.
Swift, SwiftUI, and UIKit Questions
iOS DEVELOPER INTERVIEW: SWIFT AND THE APPLE FRAMEWORKS
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Use this in the technical round. If you are not technical yourself, ask the
questions exactly as written and judge the shape of the answer against the notes
below: a strong candidate explains the idea plainly and gives a real example from
their own work. Vagueness or jargon with no example is the signal to slow down.
QUESTIONS
1. What is an optional in Swift, and when would you force-unwrap one?
(Good answer: an optional is how Swift says a value may be missing. They
prefer if-let or guard-let and force-unwrap only where the value cannot be
missing. Someone who force-unwraps to make a compiler warning go away is
telling you how your crash reports will look.)
2. When do you reach for a struct and when for a class?
(Good answer: value types are copied and are the default in Swift; reference
types are shared and used when identity or inheritance matters.)
3. Explain a retain cycle and how you would fix one.
(Good answer: two objects holding each other, most often a closure capturing
self strongly. Fixed with a weak or unowned capture and weak delegates. They
should mention finding leaks in Instruments.)
4. How do you keep slow work off the main thread, and how do you get back to it
to update the interface?
(Good answer: async and await with structured concurrency, actors for shared
state, and UI updates on the main actor. Older answers using GCD queues are
acceptable if they explain the same discipline.)
5. Would you build our app in SwiftUI or UIKit, and why?
(Good answer: a decision, not a preference. They weigh the minimum iOS version
we support, the complexity of the screens, and the fact that the two
interoperate. Someone who dismisses either one outright is worth probing.)
6. How do you store data on device, and how do you choose?
(Good answer: matches the tool to the need, from simple stored preferences up
to a real database layer, and can explain how they handle migrations when the
data model changes.)
7. Tell me about a performance problem you fixed. How did you measure it?
(Good answer: a specific symptom, a profiling tool, a measurement before and
after. "I optimized the code" without a number is not an answer.)
8. How do you handle a screen that has to work on a bad network or offline?
(Good answer: cached state, clear loading and error states, retries, and a
view of what the user sees while it fails.)
WHAT TO LISTEN FOR
•Plain explanations of technical ideas, with a real example attached
•Measurement rather than assertion on anything about performance
•Decisions framed around your product, not around fashion
NOTES
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
The set most question lists leave out. Who holds the Apple Developer Program account, signing and provisioning explained in plain language, TestFlight, review time in the schedule, and the first hour after a crash spike.
App Store Review and Release Questions
iOS DEVELOPER INTERVIEW: APP STORE REVIEW AND RELEASES
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
This is the set most interview-question lists skip, and it is the one that
protects the business. On iOS you cannot push a fix the way you push a website:
every build goes through Apple’s review before your users can get it. A developer
who has never owned that path will discover it on your deadline.
QUESTIONS
1. Who should hold our Apple Developer Program account, and under whose name
should it be enrolled?
(Good answer, and this is close to a pass or fail: the company, enrolled as an
organization under the business entity, with the owner as the account holder
and the developer given a role beneath that. A shrug here, or a suggestion to
register it under their personal account, is the most expensive red flag on
this page.)
2. Explain signing certificates and provisioning profiles to me as if I were the
owner, which I am.
(Good answer: plain language, plus a plan for who holds the distribution
certificate and where the private key is backed up. Losing it is recoverable
but disruptive, and they should treat it as company property.)
3. How do you use TestFlight before a release?
(Good answer: internal testers first, then a wider external group, with real
feedback collected. They should know external builds go through a review too.)
4. Walk me through submitting a build for review. How long do you budget?
(Good answer: they build in review time rather than promising a launch date
that assumes instant approval, and they know an expedited review can be
requested for a genuine emergency and not for poor planning.)
5. We release, and crash reports spike within an hour. What do you do?
(Good answer: pause the phased release so the damage stops spreading, confirm
the cause from crash reports, fix, and submit. Crucially, they know a shipped
iOS build is not a web deploy you can instantly revert, so the answer includes
telling you honestly how long the fix will take.)
6. What goes into our App Store privacy details, and how do you know they are
accurate?
(Good answer: the data the app collects, including anything collected by
third-party components they added, and the required tracking permission prompt
if the app tracks users. They should treat the questionnaire as a factual
disclosure, not as marketing copy.)
7. Who writes the release notes, the screenshots, and the store listing?
(Good answer: they have done it or will work with you on it. Someone who
considers the listing beneath them leaves you doing it at midnight.)
8. If Apple rejected our app the week of a launch, how would you tell us?
(Good answer: early, with the guideline quoted and two options. Watch for
anyone who describes hiding the problem until it is fixed.)
WHAT TO LISTEN FOR
•Company ownership of the developer account, keys, and listing, without argument
•Realistic release planning that includes review time
•A calm, specific incident response rather than a promise it will not happen
NOTES
__
Set 4: Architecture, Testing, and Accessibility Questions
What the app will cost you in year two: how it is structured, what gets tested and what deliberately does not, restraint about dependencies, larger text and VoiceOver, iPad support, and how they review their own work when they work alone.
Architecture, Testing, and Accessibility Questions
The questions that reduce the risk of a single point of failure: what you would need if they left, disagreeing with a non-technical owner, thin requirements, estimates and early warnings, and whether they looked at your product before the call.
Ownership, Handover, and Working With You
iOS DEVELOPER INTERVIEW: OWNERSHIP AND WORKING WITH A SMALL TEAM
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
At a small business the iOS developer is often the only person who understands
the app. That concentration of knowledge is the real risk of the hire, and these
questions test whether the candidate reduces it or deepens it. Ask them of every
finalist, employee or contractor.
QUESTIONS
1. If you left in three months, what would I need in order to hand this app to
someone else?
(Good answer: repository access, the developer account, signing assets,
documentation, and the build steps written down. A candidate who has thought
about this before you asked is the one you want.)
2. Tell me about a time you disagreed with a decision from someone
non-technical. What did you do?
(Good answer: they made the tradeoff visible in business terms, then
committed to the decision. Contempt for the non-technical side is
disqualifying when the non-technical side is you.)
3. I ask for a feature and describe it badly. What happens next?
(Good answer: questions about the user problem before an estimate. Silence
followed by the wrong feature is what you are screening out.)
4. How do you estimate work, and what do you do when you are going to miss?
(Good answer: breaks work down, gives ranges, and raises the warning early
rather than on the due date.)
5. How do you keep me informed without meetings I do not need?
(Good answer: a written cadence, a visible board, and builds we can actually
try on our phones.)
6. What would you want to change about our current app in the first month?
(Good answer: they downloaded it. Even one specific, respectful observation
beats a generic answer.)
7. Have you worked as the only developer before? How did that go?
(Good answer: honest about the isolation and about how they stayed current,
whether through a community, a mentor, or contract work.)
WHAT TO LISTEN FOR
•Knowledge spread on purpose, not hoarded
•Respect for non-technical decision makers
•Early warning as a habit
•Evidence they looked at your product before the interview
NOTES
__
Set 6: iOS Developer Scorecard and Red Flags
A six-area 1-to-5 rubric with space for evidence, an iOS-specific red-flag list, and a business-protection checklist covering the Apple account, the signing key, the repository, and the IP assignment. Use it with every set above.
iOS Developer Scorecard and Red Flags
iOS DEVELOPER INTERVIEW SCORECARD AND RED-FLAG CHECKLIST
Candidate: __
Business: __
Interviewer: __
Date: _
HOW TO SCORE
Score each area from 1 to 5 immediately after the interview, while the answers
are fresh, and write the evidence next to the number. If more than one person
interviews, each scores alone before anyone talks. Use the same six areas for
every candidate so you compare evidence rather than impressions.
Rating scale:
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
SCORING AREAS
Shipped work: a real app you can install, with a clear account of their part
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Swift and framework depth: optionals, memory, concurrency, SwiftUI or UIKit
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Release ownership: signing, TestFlight, App Store review, incident response
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Architecture and testing: structure, test line, dependency restraint
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication: explains technical choices plainly, warns early
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Ownership and handover: spreads knowledge, accepts company control of assets
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
RED FLAGS (WEIGH CAREFULLY)
[ ] No app you can install and no plain explanation of why
[ ] Has written iOS code but never owned a submission or a release
[ ] Casual about the developer account, signing keys, or who owns the code
[ ] Every past failure was somebody else’s fault
[ ] Cannot explain a technical choice without jargon
[ ] Dismisses testing entirely, or promises to test everything
[ ] Will not agree to company ownership of accounts and repositories
BUSINESS-PROTECTION CHECKLIST (SETTLE BEFORE THE OFFER)
[ ] Apple Developer Program enrolled under the company, owner as account holder
[ ] Distribution certificate and its private key backed up by the business
[ ] Source code in a repository owned by the company
[ ] Intellectual property assignment signed before any code is written
[ ] Named accounts for every service, each one revocable by the owner
[ ] Build and release steps written down somewhere other than one person’s head
Judge three things you can hear regardless of your background: specificity, evidence, and clarity. A strong answer names a tool, a guideline, a measurement, or an outcome. A weak answer stays at the level of a job description. This is the same skill you already use when hiring an accountant or an electrician, applied to a different vocabulary.
Walk me through everything between your finished code and the app being on my phone.
Strong answer: An archived and signed build in Xcode, uploaded to App Store Connect, tested through TestFlight, submitted for Apple’s review, then released, often as a phased rollout they can pause. A strong candidate volunteers that review time has to be in the schedule.
Weak answer: A weak answer stops at pushing code to the repository, or treats the App Store as a formality that happens to somebody else.
Explain a retain cycle and how you would fix one.
Strong answer: Two objects keeping each other alive, most often a closure that captures self strongly, fixed with a weak or unowned capture and weak delegate references. A strong candidate mentions finding the leak with a profiler rather than guessing.
Weak answer: A weak answer recites the definition with no example, or has never chased a memory problem in a real app.
Who should hold our Apple Developer Program account?
Strong answer: The company, enrolled as an organization under your business entity, with you as the account holder and the developer added underneath. A strong candidate raises this before you do and treats signing keys as company property.
Weak answer: A weak answer offers to register it under their own account for speed, or has no opinion about who holds the keys.
One more rule of thumb: ask the same follow-up every time, which is some version of what happened in the end. Strong candidates have the result ready, including the ones that went badly. Weak candidates retreat into generalities. If you want an extra check, invite a technical advisor to score the same rubric independently, and read how to run the interview before your first call.
The Apple Account Questions Most Lists Skip
Ask who should hold the Apple Developer Program account, and enroll it under your company rather than a person. This is the highest-value question on the page, because the accounts and keys behind an iOS app are the assets that decide whether you can still ship after the developer leaves. It costs nothing to settle in the interview and a great deal to fix later.
Ask this
What a good answer contains
Who should hold our developer account?
The company, enrolled as an organization, owner as account holder
Where does the distribution certificate live?
Backed up by the business, treated as company property
Where does the source code live?
A repository owned by the company, developer added to it
What is in our App Store privacy details?
The data collected, including by any third-party components added
What would I need if you left tomorrow?
Accounts, keys, documentation, and written build and release steps
The Mistake That Blocks a Release
Registering the developer account, the store listing, or the domain in a contractor's personal name is the most common expensive mistake a small business makes with a mobile app, and it is almost always discovered at the worst moment: a release is blocked, and the only person who can unblock it is not answering. Settle ownership during the interview, put it in the agreement, and verify it before the first build. A good candidate agrees without being asked twice.
Follow-Ups and Red Flags
The prepared questions open the conversation; the follow-ups decide it. Push for the specific version, the actual guideline, the number, the outcome. Below are the four patterns that most often separate a candidate who interviews well from one who will carry your app.
Nothing you can install
The screening set assumes a shipped app behind every answer. A candidate who cannot point at one, or explain plainly why it is internal, is answering from theory.
Wrote iOS code, never shipped it
Plenty of good engineers have never submitted a build because a release manager did it. That is fine on a team and disqualifying if this is your only mobile hire.
Casual about the Apple account
An offer to enroll the developer account under a personal name, or a shrug at where the signing key lives, is the single most expensive answer on this page.
Every past outage was somebody else
Ask about the worst production incident they were part of. A candidate who owns none of it will not warn you about the next one either.
None of these is automatically disqualifying on its own, and context matters: a developer from a large company may never have owned a submission simply because the company did not let them. Weigh each flag against the role you are filling, and write the reasoning on the scorecard so the decision survives a week of other work.
A Paid Work Sample Instead of a Whiteboard
Replace the algorithm puzzle with a small, paid work sample tied to your actual app. Ask for one screen built against a sample data source, or one specific bug fixed in a stripped-down copy of your project, capped at a few hours. It predicts the job better than a puzzle, because it is the job.
Pay for the time. Long unpaid take-home projects filter for candidates with spare evenings rather than for skill, and the strongest people simply decline. Paying also keeps you on the right side of the line when the work genuinely benefits your business, which the Department of Labor treats as compensable under its hours worked guidance. This is general information, not legal advice.
The debrief matters more than the code. Ask why they made each choice, what they would do differently with another week, and what they deliberately left out. A candidate who can defend their tradeoffs to a non-technical listener is showing you the exact skill you will rely on every week after they start. Pair the work sample with a structured skills assessment if you want a second data point.
Scoring the Interview
Score six areas from 1 to 5 immediately after each interview, with the evidence written next to the number. Scoring later, or scoring from memory at the end of a week of candidates, is how a charming interview beats a better developer. The rubric in set six is built for exactly this.
Scoring area
What a 5 looks like
Shipped work
A live app you can install, with a clear account of their part
Swift and framework depth
Plain explanations backed by a real example and a measurement
Release ownership
Owns signing, TestFlight, submission, and the crash-spike response
Architecture and testing
Choices sized to your app, a defensible test line, few dependencies
Communication
Explains tradeoffs without jargon and warns early
Ownership and handover
Spreads knowledge, accepts company control of accounts and code
If more than one person interviews, each should score alone before the group talks, so the loudest opinion does not anchor everyone else. Compare the written evidence first and discuss only the disagreements. Use a standard evaluation form across every role you hire, and close the loop with a proper interview feedback step before you decide.
Fair, Legal, and Structured Interviewing
Asking every candidate the same job-related questions, scored on the same rubric, is both the fairer approach and the more accurate one. It keeps the conversation off protected characteristics, it reduces bias, and it produces a decision you can explain months later. This is the part the question lists skip.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and a question that probes one creates risk even when it is asked as small talk. Skip age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. In a developer interview the traps are friendly ones: how long ago did you graduate, where are you originally from, whether they have kids at home while working remotely. You may ask whether the candidate can perform the essential functions of the job and whether they are authorized to work. Every question in the sets on this page is written to stay on the job. This is general information, not legal advice.
Ask the same core questions of everyone
A structured interview, where every candidate answers the same prepared questions and is scored against the same rubric, predicts on-the-job performance more reliably than a free-flowing conversation, and it is also the simplest defense of a hiring decision. For an iOS hire this matters more than usual, because the technical parts of the conversation are where an unstructured interviewer drifts, following whatever the candidate happens to be enthusiastic about. Write the questions before the first call, ask them in the same order, and score them. The sets and the scorecard here are built to make that the path of least resistance.
Do not let a technical friend decide alone
Many owners bring in a technical friend or a contractor to sit on the interview, which is a good idea. Give them the same question set and the same scorecard rather than a free hand, and have both of you score independently before you talk. Otherwise the outcome is whatever your advisor thinks of the candidate’s stack preferences, which is not the same thing as whether this person can ship and maintain your app. Compare the written evidence first, then discuss the disagreements.
Interview for your app, not for a big tech role
The famous iOS interview loops at large companies test algorithm puzzles because those companies hire hundreds of engineers into systems that already exist. You are hiring one person to own a product end to end. Weight the sets accordingly: shipping, release ownership, architecture at your scale, and communication with you. Be explicit about what the role must deliver in its first 90 days, then ask questions that test exactly that rather than borrowing an interview built for a different problem.
Same Questions, Same Rubric, Better Hires
A structured, job-related process keeps hiring decisions off characteristics protected by federal law, and a structured interview, where every candidate answers the same prepared questions against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Structure is the fairer and the more effective option at the same time.
Keep every question tied to building and shipping your app, and skip the friendly small talk that strays into age, family, origin, or health. If you want the longer version, see our guide to questions employers cannot ask. This is general information, not legal advice.
What an iOS Developer Costs
There is no separate federal wage series for iOS developers, so benchmark against software developers, occupation code 15-1252, and adjust for your metro area and the seniority you actually need. Compensation for this occupation spreads more widely than most, so the median alone is a weak planning number.
Median $135,980 a Year (BLS OEWS, May 2025)
Software developers had a median annual wage of $135,980, with the lowest ten percent under about $82,460 and the highest ten percent over about $214,670, according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey published in May 2025. The occupation held roughly 1.69 million jobs in 2024, with about 115,200 openings projected each year on average.
Decide the shape of the role before the number. A contractor or an employee serve different problems: a contractor fits a defined build with a finish line, while an employee fits an app that will keep changing, because continuity of knowledge is the scarce resource with a mobile product.
Consideration
Contractor
Employee
Fits a defined project with an end date
Fits an app that keeps changing for years
Available for the next urgent production fix
Needs an explicit IP assignment in writing
Company must hold the Apple account and keys
Classification is a legal question rather than a preference, turning on control and the economic reality of the relationship. For an employee, check whether the position meets the computer employee exemption from overtime, which the Department of Labor sets out in Fact Sheet 17E: the duties test plus either the standard salary level of $684 per week or an hourly rate of at least $27.63. Job titles do not decide it. This is general information, not legal advice.
Interviewing an iOS Developer Without HR
A large company runs this hire through coordinated panels and a recruiter who owns the scorecards. A small business runs it through the owner, usually alone, usually without the technical background to grade the code. Here is how to make one person's interview as rigorous as a hiring team's, and where the avoidable mistakes actually happen.
You are hiring an iOS developer and you do not write Swift
Most owners making this hire cannot evaluate the code, and the standard advice, run a technical screen, assumes an engineering team you do not have. That is why every question in these sets comes with what a good answer sounds like. You are not grading Swift. You are judging whether the answer is specific, whether it is grounded in something the candidate actually shipped, and whether they can explain it to you without contempt or jargon. Those three signals are available to any interviewer, and they correlate with the thing you care about, which is an app that ships and keeps working after this person moves on.
One person will hold the entire app in their head
At a small business the iOS developer is usually the only person who understands the app, the release process, and the accounts it depends on. That concentration is the real risk of the hire, and it is not solved by finding a nicer candidate. It is solved by asking the handover question in the interview, by enrolling the Apple Developer Program under your company rather than a person, by keeping the source code in a repository you own, and by requiring the build and release steps to be written down. A good candidate agrees to all of this immediately, and frequently raises it before you do.
The interview ends and the risky part begins
Once you choose someone, the exposure moves from evaluation to setup: an intellectual property assignment signed before the first line of code, a confidentiality agreement, access granted to named accounts you control, and the Apple account and signing keys held by the business. This is the part FirstHR handles for a small team: send the offer and the agreements for e-signature, run the onboarding tasks for account setup and policy sign-off, and keep every signed document on the employee profile instead of scattered across inboxes. FirstHR is an onboarding and HR platform, not a development tool or a code repository, so pair it with those. Applicant tracking is coming soon to FirstHR.
Browse the rest of the hiring templates if you need the offer and evaluation paperwork too, and use the broader mobile developer posting when the role covers both platforms. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is step one. Once you choose someone, the work shifts to a clean start: a written offer with the classification stated, an intellectual property assignment and a confidentiality agreement signed before any code is written, and access granted to named accounts you can revoke.
Offer and IP assignment
Put the role, pay, and classification in writing, and get the intellectual property assignment signed before any code is written for you.
Access you can revoke
Repository, crash reporting, analytics, API keys, and App Store Connect, each granted to a named account under your control.
Apple assets held by the company
Developer Program enrolled under the business entity, you as account holder, and the distribution certificate and key backed up by the company.
Records in one place
Signed offer, confidentiality agreement, I-9, W-4, and policy acknowledgments filed against the employee profile rather than an inbox.
Then run the standard paperwork alongside the technical setup: the I-9, the W-4, and the policy acknowledgments, plus a first-week plan if the person is joining remotely. FirstHR connects the offer, the agreements, e-signature, and the onboarding tasks in one place, and keeps every signed document on the employee profile so a small business can run the whole hiring-to-onboarding path from one system. FirstHR is an onboarding and HR platform, not a development tool or a code repository, so pair it with those. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess five areas: shipped iOS work, Swift and framework depth, release ownership, architecture and testing, and how they work with you.
The best screening question is what happens between finished code and the app being on your phone, because it separates a coder from an app owner.
You do not need to read Swift: judge whether the answer is specific, anchored to shipped work, and explained without jargon.
Enroll the Apple Developer Program under your company, keep the signing key and repository company-owned, and settle it during the interview.
Replace the algorithm puzzle with a short paid work sample on your real app, and treat the debrief as the signal.
Score six areas from 1 to 5 with written evidence right after each interview, and have any technical advisor score the same rubric independently.
Benchmark pay against software developers, a $135,980 national median in the BLS survey published May 2025, then adjust for your market.
Frequently Asked Questions
What questions should I ask an iOS developer in an interview?
Ask questions that test five things: shipped work, Swift and framework depth, release ownership, architecture and testing, and how they work with you. The strongest opening question is to name an app they shipped that you can download and describe exactly what they owned on it. Follow with a walkthrough of everything that happens between finished code and the app being on your phone, which separates someone who writes iOS code from someone who owns an app. Then ask about an App Store rejection they received, what they do when Apple announces a new iOS version each year, how they would fix a retain cycle, and what you would need if they left in three months. This page gives you six downloadable sets, and each question states why it is worth asking and what a good answer sounds like.
How do I interview an iOS developer if I am not technical?
You do not need to grade Swift to run a good iOS interview. Judge three things instead: whether the answer is specific, whether it is anchored to something the candidate actually shipped, and whether they can explain it to you plainly without jargon or condescension. Every question in these sets comes with a note on what a strong answer sounds like, so you can hear the difference between a real practitioner and a rehearsed one. Two questions do most of the work: ask them to walk you through the path from finished code to the App Store, and ask what you would need in order to hand the app to someone else. Add a short paid work sample on your real codebase if you want a technical check, and have a trusted technical advisor score the same rubric independently rather than deciding alone.
What is the best screening question for an iOS developer?
Ask the candidate to walk you through everything that happens between their code being finished and the app being on your phone. A developer who has owned an app describes archiving and signing the build in Xcode, uploading it to App Store Connect, distributing it through TestFlight for testing, submitting it for Apple review, and then releasing it, often as a phased rollout they can pause if something goes wrong. Someone who has only written features on a larger team will stop at pushing code to the repository, because a release manager handled the rest. Neither answer is disqualifying by itself, but the difference matters enormously when this person will be your only mobile hire and the release is theirs to own.
Should I ask an iOS developer to complete a coding test?
A short, paid work sample tied to your actual app is more useful than an algorithm puzzle. Ask for something small and realistic, such as building one screen against a sample data source or fixing a specific bug in a stripped-down copy of your project, and cap it at a few hours. Pay for the time, and treat the debrief as the real signal: ask why they made each choice, what they would do differently with a week, and what they deliberately left out. Long unpaid take-home projects push away the strongest candidates, who have options, and they select for free time rather than for skill. If the work you request genuinely benefits your business, paying for it is also the safer position under wage and hour rules. This is general information, not legal advice.
Who should own the Apple Developer Program account, my company or the developer?
Your company, always. Enroll the Apple Developer Program under your business entity as an organization, with you or another owner as the account holder, and add the developer to the account with a role beneath that. The same rule covers the App Store Connect listing, the distribution certificate and its private key, the source code repository, and every service the app depends on. Registering the developer account in a contractor's personal name is one of the most common and most damaging mistakes a small business makes with a mobile app, and it is usually discovered at the worst possible moment, when that person is unreachable and a release is blocked. Ask the ownership question in the interview. A good candidate agrees immediately and often raises it before you do.
What are the red flags in an iOS developer interview?
The biggest red flag is no shipped app you can install and no plain explanation of why, because the entire job is getting software through Apple review and onto real devices. Close behind it is a candidate who has written iOS code but has never owned a submission or a release, which is normal on a large team and disqualifying if this is your only mobile hire. Watch for casual answers about the developer account, the signing key, or who owns the code. Watch for a candidate who claims never to have been rejected by App Store review, which usually means they never submitted. Also weigh softer signals: contempt for non-technical decision makers, a past in which every failure belonged to someone else, and an inability to explain a technical choice without jargon.
How much does an iOS developer cost to hire?
There is no separate federal wage series for iOS developers, so benchmark against software developers, occupation code 15-1252. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey published in May 2025, software developers had a median annual wage of about $135,980, with the lowest ten percent under roughly $82,460 and the highest ten percent over roughly $214,670. Adjust for your market, since compensation varies widely by metro area, and for the shape of the role: a contractor on a defined project bills differently from an employee who will maintain the app for years. Before you set a number, decide whether the position is exempt from overtime under the computer employee exemption, because the classification affects total cost. This is general information, not legal advice.
Is a contractor or an employee better for a first iOS hire?
It depends on whether the app is a project or a product. A contractor fits a defined build with a clear finish line, and costs less in benefits and overhead, but the arrangement leaves you dependent on someone whose attention is divided and who may not be available for the next urgent fix. An employee fits an app that will keep changing, because continuity of knowledge is the scarce resource with a mobile product. Whichever you choose, the classification is a legal question, not a preference: it turns on the degree of control and the economic reality of the relationship, not on the label in the agreement. Get the intellectual property assignment signed either way, and keep the Apple account, the signing keys, and the repository under company ownership. This is general information, not legal advice.
