A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
The iOS market is split twice over, and most job descriptions acknowledge neither split.
The first is UIKit to SwiftUI. SwiftUI is where Apple is going and where new code gets written, but almost every established app is a mixed codebase held together by UIHostingController and UIViewRepresentable. A developer who has only written SwiftUI struggles in a UIKit app with a decade of view controllers. A developer who has only written UIKit writes SwiftUI that fights the framework.
The second is Swift Concurrency. async/await, actors and Sendable are not a nicer syntax for completion handlers — they are a different model with compile-time data-race checking behind them, and Swift 6 turns what used to be warnings into errors. Adopting it in an app built on Grand Central Dispatch and Combine is a real migration with a long tail.
Ask which parts of the app a candidate has actually migrated. "Familiar with SwiftUI" is the most over-claimed line on an iOS CV.
iOS screening is mostly about which of the two live migrations somebody has actually done.
Which they have actually shipped, and whether they can work across the bridge in a mixed codebase. We do not accept the two as one skill.
async/await, actors, Sendable and main-actor isolation — and whether they have taken an existing app through strict concurrency checking.
Whether they have been rejected, what for, and what they changed. Candidates who have never submitted a build are a different proposition.
Capture semantics in closures and whether they use Instruments to confirm rather than adding weak self everywhere by reflex.
Certificates, provisioning, TestFlight and phased release. On small teams this is the work that quietly falls to nobody.
A live conversation in English, every time. Review constraints need raising while a feature is being designed, not after it is built.
The distinctive iOS cost is that somebody else decides when you ship.
App Store review is a real gate, and it is not only about crashes. Guideline 3.1.1 governs what you must sell through in-app purchase. Guideline 5.1.1 governs what data you may ask for and why. Privacy manifests now matter: an app using certain APIs has to declare a reason, and the third-party SDKs you depend on need their own manifests and signatures. An analytics SDK two versions behind can be the thing that blocks a release, and you find out at submission rather than in development.
A developer who has never been rejected has never shipped anything interesting. What you want is somebody who reads the guidelines before building the feature, so the payment flow, the tracking prompt and the account-deletion path are right the first time. Reworking those after a rejection means a new build, a new review cycle, and a launch date that moves by a week you did not have.
Then there is the September problem. Every autumn a new iOS version ships, APIs deprecate, and behaviour changes. Apps without an owner drift out of compliance quietly — until an SDK requirement or a minimum-target change makes the next update impossible without a fortnight of unplanned work. Teams that treat iOS as done after launch pay this bill repeatedly.
Mid-level (3–5 years). Builds screens and features against an existing architecture. Comfortable with Swift, one of UIKit or SwiftUI, networking and persistence. Has shipped to TestFlight, usually not owned a release.
Senior (5–8 years). Owns architecture decisions and the SwiftUI adoption path. Handles signing, provisioning and release, and has taken an app through review including at least one rejection. Reads Instruments rather than guessing at performance.
Lead (8+ years). Owns the mobile platform, sets the concurrency migration strategy, manages the annual OS cycle deliberately, and makes the native-versus-cross-platform call with reasons rather than preference.
Feature work on an existing app. The largest category. Be explicit about UIKit, SwiftUI or both, because it changes who fits.
SwiftUI migration. Moving an established UIKit app screen by screen. Needs someone genuinely comfortable on both sides of the bridge.
Swift Concurrency adoption. Retiring completion handlers and getting clean under strict concurrency checking. Bounded, technical, and consistently underestimated.
New app builds. Usually SwiftUI-first now, with UIKit reached for where the framework still falls short.
iOS alongside Android or a cross-platform app. See Android, Flutter and React Native developers.
Week one. They get the app building and signed on their own machine, which on an established iOS project is genuinely a test. Expect questions about the UIKit and SwiftUI boundary, what the concurrency story currently is, and which third-party SDKs are in the dependency list and how current they are.
Weeks two to four. A shipped feature that goes through your review and into TestFlight. Expect them to have read the App Store guidelines relevant to what they built, and to raise anything in the existing app that would not survive review today — an outdated SDK, a missing privacy manifest, a permission prompt with a weak justification string.
The warning sign is a developer who only works in Simulator. Simulator does not exercise memory pressure, real network conditions, background termination or push notification delivery honestly. Somebody who has not put a build on a physical device in the first fortnight is not testing the things that fail.
Screening for "iOS" instead of for the UI framework. The gap between a UIKit-only and a SwiftUI-only developer is wide enough to cost you a month. Say which your app is, and if it is both, say that too — plenty of good candidates are strong on one side and honest about the other.
Treating App Store review as an administrative step. It is a design constraint. Payment flows, account deletion, tracking prompts and data declarations all have to be built to the guidelines, not retrofitted. Involve somebody who has been rejected before, because they build differently.
Underestimating Swift Concurrency adoption. Sprinkling async onto existing code produces a codebase that compiles and still races. Getting clean under strict checking means thinking about actor isolation and what genuinely needs to be on the main actor. Budget it as a project, not a refactor.
No owner between releases. iOS moves on an annual cycle whether or not you are paying attention. An app with no maintainer accumulates deprecations, SDK requirements and minimum-target changes until a small update becomes a fortnight of work. A few days a quarter avoids that entirely.
Rates depend on seniority, framework depth, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.