Hire iOS and Swift developers

iOS development is Swift plus a platform with strong conventions and a review process, and hiring for it means valuing shipping experience as much as language knowledge.

What iOS and Swift actually is

iOS development means building applications for Apple's mobile platform, primarily in Swift, using Apple's frameworks and tooling. Swift is a modern typed language with strong safety guarantees, and the platform around it is unusually opinionated: Apple supplies the interface frameworks, the development environment, the distribution channel and the rules about what an application may do.

That vertical integration is the defining characteristic. It means excellent tooling and consistent user expectations, and it means that Apple's decisions become your constraints. The review process, annual platform releases, privacy requirements and deprecations all arrive on Apple's schedule. A developer who has shipped and maintained applications through several of those cycles brings knowledge that is unglamorous and genuinely valuable.

The current complication for hiring is the presence of two interface frameworks. The older one is imperative and mature, with a very large body of existing code. The newer declarative one is where Apple is investing and where most new work starts, and it is still filling gaps. Most serious applications now contain both. A candidate who knows only one of them is a partial fit for most real codebases.

The part that separates seniors from mid-levels

Memory management is the first thing that separates levels. Swift uses automatic reference counting, which is deterministic and imposes a real obligation: reference cycles are not collected, so a closure capturing self strongly inside a long-lived object leaks. This is the classic iOS bug, it does not announce itself, and it accumulates. Developers who have used the memory graph debugger to find a retain cycle are describing experience you want.

Concurrency has changed substantially with structured concurrency and the actor model, which move a class of data race from a runtime surprise to a compile-time error. This is one of the more significant shifts the platform has made, and it divides candidates cleanly: those who have adopted it think about isolation and where code runs, while those whose experience predates it think in terms of dispatch queues and completion handlers. Both can work; only one is aligned with where the platform is going.

The third area is the declarative interface framework's update model, which catches out developers arriving from the imperative one. Views are a function of state, and the framework decides when to re-evaluate them. Understanding which property wrapper creates ownership, which observes, and what causes an unnecessary re-render is the practical skill, and it is where performance problems and puzzling behaviour both originate.

Where iOS and Swift is used

The label “iOS and Swift developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Consumer applications

Products where iOS users are the primary or most valuable audience and platform polish is a differentiator.

Financial services

Banking and investment applications, where platform security features and biometric authentication are central.

Health and fitness

Applications integrating with health data and wearables, an area with strong platform support and strict privacy rules.

Enterprise and field applications

Internal applications distributed through managed deployment rather than the public store.

Media and entertainment

Streaming and content applications, where playback, background audio and offline behaviour are the hard parts.

Hardware companion applications

Applications pairing with physical devices over Bluetooth, where the platform's connectivity behaviour is the main challenge.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which iOS and Swift versions are still supported

Apple releases a major iOS version annually and deprecates APIs on a predictable schedule, so the minimum supported version an application targets is a live commercial decision rather than a setting.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 5 are still maintained and 3 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for iOS and Swift alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Swift

The language. Objective-C knowledge remains useful for older codebases and diminishing elsewhere.

SwiftUI and UIKit

The declarative and imperative interface frameworks. Most real applications contain both.

Swift Concurrency

Structured concurrency and actors, now the expected approach for asynchronous work.

Xcode

The development environment, including Instruments for profiling and the memory graph debugger.

Swift Package Manager

Dependency management, now the default over older third-party tools.

Core Data or SwiftData

Local persistence, including offline behaviour and synchronisation.

XCTest and XCUITest

Unit and interface testing, run on simulators and devices.

Fastlane and App Store Connect

Build automation, signing, distribution and release management.

Related skills that frequently appear on the same specification: TypeScript, React Native, Flutter, Android and Kotlin, AWS.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Retain cycles and memory

The classic iOS defect, invisible until it is a problem.

• Strong answer: Explains strong and weak capture, uses the memory graph debugger, and can describe a leak they found.
• Warning sign: Captures self strongly in long-lived closures without thinking about it.

Swift Concurrency and actors

The clearest test of whether their knowledge is current.

• Strong answer: Uses structured concurrency, understands actor isolation and main-actor annotation, and can explain what the compiler now catches.
• Warning sign: Works entirely in dispatch queues and completion handlers, which places their experience several years back.

SwiftUI state ownership

Where declarative interface bugs and performance problems originate.

• Strong answer: Explains which property wrapper owns state versus observes it, and can diagnose an unnecessary re-render.
• Warning sign: Uses state wrappers interchangeably and cannot explain the difference.

Mixing the two interface frameworks

Most real codebases do, so working in only one is a partial fit.

• Strong answer: Has embedded one in the other in both directions and knows where the boundary gets awkward.
• Warning sign: Has only worked in one and would avoid the other.

App Store review and rejections

Unavoidable, and expensive to learn during a launch.

• Strong answer: Has handled a rejection, understands the privacy and data-use requirements, and plans submissions with review time included.
• Warning sign: Has built applications but never shipped one to the store.

Background execution and lifecycle

iOS is strict about what runs when the application is not in front.

• Strong answer: Knows the background modes, handles termination and restoration, and designs for the system suspending work.
• Warning sign: Assumes work continues in the background as it would on a desktop.

Testing on real devices

Simulators hide performance, memory and connectivity behaviour.

• Strong answer: Tests on physical devices including older models, and profiles with Instruments.
• Warning sign: Develops and validates entirely in the simulator.

Warning signs in a iOS and Swift codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Retain cycles in closures

• What you see: Self captured strongly in an escaping closure held by a long-lived object.
• What it costs: View controllers and their entire object graphs never deallocate, and memory grows with navigation.
• The fix: Capture weakly and guard. Check the memory graph after building any screen that holds a closure.

Massive view controllers

• What you see: A single controller of thousands of lines holding networking, business logic and presentation.
• What it costs: Nothing is testable in isolation and every change risks unrelated behaviour.
• The fix: Extract networking and logic into separate types with clear inputs and outputs. The controller should coordinate.

Blocking the main thread

• What you see: Network calls, disk access or heavy decoding performed synchronously on the main actor.
• What it costs: A frozen interface, and in the worst case a watchdog termination that appears as a crash.
• The fix: Move work off the main actor and update the interface on it. Structured concurrency makes this explicit rather than conventional.

Force unwrapping

• What you see: The exclamation mark used routinely to satisfy the compiler.
• What it costs: Crashes in production for exactly the condition the type system was warning about.
• The fix: Unwrap conditionally and handle the absent case. Where a value genuinely cannot be nil, express that in the type rather than overriding the check at every use site.

Ignoring platform deprecations

• What you see: An application built against several-year-old APIs with warnings suppressed.
• What it costs: Eventually the application stops meeting store requirements and cannot be updated without substantial work.
• The fix: Address deprecations in the release cycle when they appear. The annual platform cadence means deferral compounds quickly.

Hardcoded secrets in the bundle

• What you see: API keys committed into the application binary.
• What it costs: Anyone can extract them from a downloaded application, and rotating them requires a store release.
• The fix: Keep secrets server-side. Where a client credential is unavoidable, scope it narrowly and make it revocable.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a iOS developer.

Junior

Builds screens within an existing application. Needs review on memory, threading and state ownership.

Mid-level

Owns a feature including its networking, persistence and tests. Can profile with Instruments and find a retain cycle.

Senior

Owns application architecture, the concurrency approach, the interface framework strategy, and the release pipeline including store submission.

Staff

Owns the platform upgrade path, the privacy and data-use posture, the boundary with any shared cross-platform code, and the response to annual platform changes.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

New iOS application

• Usual team: One to two developers plus a designer.
• What governs it: Store review, privacy declarations and device testing consume more of the schedule than teams new to mobile expect.

UIKit to SwiftUI migration

• Usual team: One senior developer.
• What governs it: Incremental by nature since they interoperate. Screen by screen is the normal and correct approach.

Annual platform update

• Usual team: One developer, recurring each year.
• What governs it: Not optional. Deprecations and store requirements arrive on Apple's schedule and must be budgeted.

Performance or memory remediation

• Usual team: One senior developer with real devices.
• What governs it: Instruments-led. Usually retain cycles, main-thread work, or image handling.

Hardware integration

• Usual team: One developer with connectivity experience.
• What governs it: Bluetooth and background behaviour are the difficult parts, not the application logic.

Migration work you may actually be hiring for

A large share of iOS and Swift work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

UIKit to SwiftUI

• Why teams do it: Less code per screen, better alignment with where the platform is going, and a faster development loop.
• What to watch: They interoperate in both directions, so migrate screen by screen. Keep UIKit where SwiftUI still has gaps rather than forcing it, and expect the navigation layer to be the awkward part.

Completion handlers and dispatch queues to Swift Concurrency

• Why teams do it: The compiler catches data races that were previously runtime surprises, and the code is substantially clearer.
• What to watch: Adopt at the boundaries first and work inward. Mixed codebases are normal for a long time, and forcing a complete conversion tends to introduce more bugs than it removes.

Objective-C to Swift

• Why teams do it: A larger hiring pool and better safety guarantees.
• What to watch: They interoperate, so this is incremental. There is rarely a business case for converting working Objective-C that nobody is touching; convert what you are already changing.

CocoaPods or Carthage to Swift Package Manager

• Why teams do it: First-party tooling, better Xcode integration and fewer build complications.
• What to watch: Some dependencies may not offer a package version. Check each one before starting, since a single holdout can require keeping the old tool alongside.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a iOS developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the application uses SwiftUI, UIKit, or both, and roughly in what proportion.
• Whether the codebase has adopted Swift Concurrency or still uses completion handlers.
• Which iOS versions must be supported, since that determines which APIs are available.
• What platform capabilities are involved: health data, widgets, background modes, Bluetooth, payments.
• Who controls the Apple developer account, signing and provisioning, because this blocks day one otherwise.
• Whether any Objective-C remains and whether the person will have to work in it.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

iOS and Swift work is counted by the US Bureau of Labor Statistics under Software Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a iOS developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 1,687,890 people in this occupation, with a median annual wage of $135,980.

The spread matters more than the midpoint. The 90th percentile is about 2.6 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a iOS developer can sit at $82,460 and $214,670 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Software Developers, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $213,110; Pittsburgh sits at the bottom with $124,500. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, San Francisco, Seattle, Washington, D.C., Denver, Austin each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

No store shipping experience. Building and shipping are different. Ask about a rejection and about how they plan around review time.

Experience predating Swift Concurrency. Ask about actors and isolation. The platform has moved and codebases are following.

Single interface framework only. Most real applications use both. Ask which parts of their last application used each.

Simulator-only testing habits. Ask which physical devices they test on. Performance and connectivity problems are invisible in a simulator.

Hiring iOS and Swift developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of iOS developer who will be available.

• New York, NY $166,830 median
• Seattle, WA $167,280 median
• San Jose, CA $213,110 median
• Washington, D.C. $154,930 median
• San Francisco, CA $186,640 median
• Dallas-Fort Worth, TX $133,290 median
• Los Angeles, CA $160,920 median
• Boston, MA $166,090 median
• Chicago, IL $134,380 median
• Atlanta, GA $132,960 median
• Austin, TX $134,120 median
• Phoenix, AZ $131,750 median
• Philadelphia, PA $133,040 median
• Minneapolis-St. Paul, MN $130,920 median
• Denver, CO $137,610 median
• Detroit, MI $130,760 median
• Houston, TX $129,440 median
• Charlotte, NC $135,920 median
• San Diego, CA $163,270 median
• Salt Lake City, UT $129,600 median
• Miami, FL $132,650 median
• Portland, OR $156,000 median
• Baltimore, MD $138,900 median
• Tampa, FL $130,450 median
• Orlando, FL $129,620 median
• Raleigh, NC $132,770 median
• Kansas City, MO $124,990 median
• Pittsburgh, PA $124,500 median

Frequently asked questions

Should we build native iOS or use a cross-platform framework?

Native when iOS is the primary platform, when the application leans on platform capabilities such as health data, widgets or deep hardware integration, or when the last increment of polish genuinely matters commercially. Cross-platform when you need both platforms from one small team and the interface is largely standard. The honest tiebreaker is usually how much of your revenue or usage is on iOS.

SwiftUI or UIKit?

New work generally starts in SwiftUI, which is where Apple is investing. UIKit remains necessary for some capabilities and represents an enormous body of existing code. In practice most serious applications contain both and interoperate between them, so a candidate comfortable only in one is a partial fit for most real codebases.

Is Objective-C still relevant?

Decreasingly, and not zero. Large older codebases still contain it, and some system-level work still benefits from understanding it. For new development it is not a requirement, and insisting on it narrows the pool for little return unless you genuinely have Objective-C to maintain.

How long does App Store review take?

Usually short, occasionally not, and it is not something you can rely on. The real planning issue is not the typical duration but the possibility of a rejection requiring changes and a resubmission. Teams that schedule a launch with no slack for one rejection cycle are the ones that miss dates.

Why does our iOS application use more memory the longer it runs?

Almost always retain cycles, typically closures capturing self strongly in objects that outlive the screen. Memory grows as users navigate and never comes back. The memory graph debugger in Xcode finds these reliably, and a developer who has done it once can usually identify the pattern across a codebase in a day.

Do we need to update the application every year?

Effectively yes. Apple releases a major platform version annually, deprecates APIs, and periodically changes store requirements such as the minimum build tooling. An application that is not maintained will eventually be unable to ship an update without substantial remedial work. Budget for this as recurring maintenance rather than as a project.

What does a Swift developer need from us on day one?

Access to your Apple developer account or a clear path to it, signing certificates and provisioning that work, and a test device. Signing and provisioning are the single most common reason an iOS developer's first days are unproductive, and it is entirely an administrative problem on your side.

Can an Android developer build our iOS application?

Not immediately, though the mobile judgement transfers well: lifecycle, offline behaviour, store processes and device constraints are shared concerns. The language, frameworks and conventions are different enough to need real ramp time. A strong Android developer becomes a competent iOS developer faster than a web developer does, and it is still months rather than weeks.