iOS Developer Job Description Template 2026

Last updated: September 10, 2026

By Mike Carter, Director of Partnership Success, KORE1

Good iOS developer job descriptions in 2026 spend their words on the app: its SwiftUI and UIKit split, the oldest iOS version it supports, the Apple frameworks it relies on, and who handles App Review. Swift, Xcode, and “five years of experience” show up on every iOS posting in the country, so they sort nobody. Those four facts about the app do the sorting. This month they carry extra weight, because Apple set iOS 27’s public release for September 14, and that release brings a design change your next hire will probably end up owning.

The call that started this page came in late August, from an engineering manager at a credit union in Orange County.

I’d bet a few people reading this are in the same spot. One consumer banking app, roughly 240,000 members using it, two iOS engineers on staff. One of the two had just given notice. The manager wanted a replacement posted by Labor Day and sent me the draft to look over before it went to HR. That gave us about a week.

It was a perfectly normal iOS posting. Swift, SwiftUI, Combine, MVVM, REST APIs, unit testing, five-plus years, a line about passion for mobile. I have read that document maybe four hundred times, in a lot of different fonts.

What it left out was one line in their Info.plist. Last fall, when Xcode 26 started applying Apple’s new Liquid Glass design to every app rebuilt against the iOS 26 SDK, their team set a key called UIDesignRequiresCompatibility to YES, and the app kept looking the way it did in 2024. Honestly, a sensible call at the time. Their tab bar and navigation were custom-drawn, an accessibility audit had just wrapped, and nobody wanted to redo either one on Apple’s schedule.

The engineer who gave notice was the one who added that key. He’d also kept the reasons in his head, where they were about to leave the building with him.

Apple’s documentation for the key now carries a sentence it didn’t have a year ago. The system ignores it when you build for iOS 27 or later. The flag simply stops working. So whoever this credit union hires is going to lead a redesign of a banking app, probably inside their first two quarters, and the draft said nothing about it. We rewrote the opening paragraph around that single fact. Three days after it went up, the applicants were different people, and several of them opened by asking about the redesign, which is exactly the conversation you want a candidate to start.

You should know what I do before taking posting advice from me. My title at KORE1 is Director of Partnership Success, and in practice that puts me on the intake calls for our iOS developer staffing desk, where hiring managers describe the job they actually have before HR turns it into the job on the page. KORE1 gets paid when a company hires someone we introduced. Most of what follows needs a text editor and an honest hour with your tech lead, and nothing from us.

iOS 27 and the End of the Liquid Glass Opt-Out

Some background for anyone outside the Apple world. At WWDC in June 2025, Apple introduced Liquid Glass, a translucent material that now runs through tab bars, toolbars, sheets, and controls across iOS 26. Any app rebuilt with Xcode 26 picks it up automatically for standard UIKit and SwiftUI components. Custom components don’t. They sit there looking like 2024 beside system chrome that looks like 2026, which is the worst of both worlds.

Apple gave teams an escape hatch and was clear it wouldn’t last. The UIDesignRequiresCompatibility documentation describes the key as something to use temporarily while you rework your UI, and it now states that the system ignores the key when you build for iOS 27 or later.

Now the calendar part. Apple announced in February that starting April 28, 2026, every iOS app uploaded to App Store Connect had to be built with the iOS 26 SDK or later. That has been Apple’s rhythm for years, with a new SDK every September that becomes mandatory the following spring. If the rhythm holds, some date in spring 2027 is the last day an app can ship an update while still wearing its old design. Apple hasn’t announced that date. I would plan as though it’s April anyway.

What does that do to a job description? If your Info.plist has that key set, the job includes a redesign, and the redesign has a deadline. Apple picks the date. Engineers who have taken a custom design system through a major Apple visual change are a far smaller group than engineers who know SwiftUI. Some of them did it in 2013, when iOS 7 flattened everything. More of them did it last winter. They’re exactly who you want, and a posting that never mentions the flag gives them no reason to think the job is theirs. Most won’t apply.

The line I’d add, near the top: “Our app currently runs in Liquid Glass compatibility mode. This role leads the adoption, including our custom navigation and tab bar, before the iOS 27 SDK becomes the App Store minimum.”

Not sure whether your app uses the flag? Whoever has the repo can search the Info.plist in about a minute.

How Much of the App Is SwiftUI?

Apple introduced SwiftUI in June 2019. UIKit has been around since the first iPhone SDK in 2008. Almost every app behind the reqs we see, including plenty that were started from scratch in 2022, runs on some mix of the two, and a sentence stating that mix is the most useful thing a posting can say about the code.

Why does the percentage matter so much? The two populations have drifted apart. Engineers who started their careers after 2020 often learned SwiftUI first and treat UIKit as legacy they would rather not touch. Engineers with ten years in are the reverse, fluent in the view controller lifecycle and occasionally impatient with SwiftUI’s rough edges around navigation and long lists. Both groups can do both. Their preferences are strong, though, and a posting that says “SwiftUI” over a codebase that’s 80% UIKit tends to lose the first group somewhere in the first month, usually right after they open the main storyboard.

The language mode is the second number, and it’s newer. Swift 6 arrived in September 2024 with complete data-race checking in the Swift 6 language mode, and a lot of teams turned it on, watched several hundred errors appear, and turned it back off. Swift 6.2 softened things considerably. The Swift 6.2 release announcement added an option to isolate code to the main actor by default, and new projects created in Xcode 26 start out that way. Existing projects don’t. So a real iOS codebase is in one of three states right now: still on the Swift 5 language mode, partway through the migration with warnings on, or fully on Swift 6. Each is a different first quarter for the person you hire.

A candidate asked a hiring manager at a health-tech company in Carlsbad, during a second-round interview in July, which language mode the company’s app was on. The manager didn’t know and said so, which was fine. The follow-up wasn’t. “We’ll figure it out when you start” landed badly on someone who had just spent eight months doing that exact migration at their last job and wanted to know, before signing, whether they were walking into round two of it. They accepted another offer that Friday. The manager still mentions it.

Then there’s Objective-C. The generic template sitting at the top of the search results for this role still asks for “Objective-C or Swift,” as if a 2026 hire might reasonably pick one. Nobody picks. Your app either has Objective-C in it or it doesn’t, and if it does, the amount and location matter enormously. “Some legacy Objective-C in our networking layer” and “38% of the codebase, including payments” are two different jobs. The second pays more.

All of this fits in about fifty words. The SwiftUI share, the language mode, and whether there’s Objective-C and where it lives. I’d put it directly under the paragraph describing what the app does.

The Oldest iOS Version You Support Is a Hiring Decision

Deployment target is the least glamorous field in the project settings. Nobody fights over it. It decides more about the job than most requirements sections do.

Apple publishes adoption numbers on its App Store developer support page. As measured by devices that transacted on the App Store on June 7, 2026, iOS 26 was running on 86% of iPhones introduced in the last four years and 79% of all iPhones. Most consumer apps can support the current version and one back without losing anybody who matters. Plenty of apps support a lot more than that, for good reasons, and those reasons belong in the posting.

A regional retailer we worked with last year is the cleanest example I have. Store associates ran an internal inventory app on a fleet of iPhone 7s clipped into barcode sleds, and the iPhone 7 stops at iOS 15, so the app’s deployment target was iOS 15. The posting said SwiftUI, which was technically true, and the engineer they hired arrived expecting the modern version of it. The Observation framework and SwiftData both need iOS 17. NavigationStack needs iOS 16. He spent five months writing around APIs he couldn’t use, then left for a job where he could use them. The fleet replacement, for the record, was already budgeted for the following spring. Nobody told him.

Write the target and the plan. “Supports iOS 16 and later, moving to iOS 17 in the first quarter” tells a candidate which half of the modern SDK they’ll get to touch. It also quietly tells them your team keeps that number moving, which is a signal of its own.

The Frameworks Are the Job

Here’s the part most iOS postings get backwards. They list the language and the architecture pattern, which every applicant shares, and leave out the Apple frameworks the app actually depends on, which almost no applicant shares.

An engineer who has spent three years inside HealthKit and Core Bluetooth knows things about background execution and state restoration that a strong consumer SwiftUI engineer has simply never had to learn. The reverse is true too. Naming the frameworks is how the right one of those two people recognizes the job.

The Core ML row is changing fastest. Apple’s Foundation Models framework, released with iOS 26, gives apps direct access to the on-device model behind Apple Intelligence, and since spring it has started turning up on client reqs as “AI experience” with no further detail. A weekend prototype and a feature that survived App Review and a few hundred thousand real users are very different lines on a resume. The posting should say which one you need.

Put two framework names in the first paragraph and the wrong applicants start reading your posting as somebody else’s job, which is the whole idea. If the work is mostly screens and networking against your own backend, say that instead. It’s a legitimate job. Plenty of good engineers want it. It just isn’t any of the jobs in that table. Our guide to hiring an iOS developer splits the role into consumer, SDK, media, and platform tracks if you want the longer version of this argument.

Apple Rejected 2.09 Million Submissions Last Year

Apple’s 2025 App Store Transparency Report counts 9,100,620 app submissions reviewed and 2,093,244 rejected, about 23%. Another 387,087 were approved after the developer fixed the problem and resubmitted. Apple’s Performance category, which covers crashes, incomplete builds, and inaccurate metadata, was the most common reason by a wide margin, at 1,354,418.

Somebody at your company reads those rejection notices. Most postings never say whether that somebody is the new hire.

At large companies it usually isn’t. Release engineering holds the signing certificates, provisioning profiles, TestFlight groups, and App Store Connect, and a senior iOS engineer can go five years without writing a single reply to App Review. At a company with two or three iOS engineers, all of that belongs to one person, and it tends to be the least documented job in the building.

A subscription fitness app in Irvine hired a senior engineer out of a very large consumer company last spring. Excellent engineer. Her first upload as the app’s new owner bounced with an ITMS-91053 error, a missing API declaration, because a newly added analytics SDK called a required reason API that the app’s privacy manifest never declared. Apple has enforced that on uploads since May 1, 2024. She fixed it in an afternoon. Then came round two. The resubmission was rejected under guideline 3.1.2 because the paywall had no link to the terms of use. Nine days from first upload to approval, on a release the marketing team had already announced.

Her last employer kept a whole release team for that part of the job. She’d never been handed it, and nobody at the new company knew she hadn’t, because the posting said “experience shipping apps to the App Store” and she had shipped plenty. Just never personally.

On intake calls I ask four ownership questions. Who holds signing and provisioning? Who submits the builds? Who answers App Review and files the appeals? Who keeps the App Privacy details and privacy manifests current? For smaller companies I’ve added a fifth, which is whose Apple ID is the Account Holder on the Apple Developer Program membership. Twice this year the answer was an engineer who no longer worked there. One had moved to Denver.

What Goes on the Pay Line

The aggregators disagree, as usual. Indeed reports an average base of $139,607 for iOS developers, drawn from 950 salaries in job postings and updated September 6, 2026. Built In puts average base at $117,644, with another $11,869 in additional cash. That’s a $21,963 gap between two sources describing the same two words. The federal figure is broader still. O*NET, which the Labor Department maintains, has no iOS category at all, so iOS engineers fall under software developers, where the 2025 median is $135,980 and roughly 115,200 openings are projected each year through 2034.

None of those is the number to post. The posted number comes from level, metro, and whatever you named from the framework table, and the table below uses the national base ranges from our iOS developer salary guide, next to the one requirement line I’d use to prove each level.

Coastal metros and big tech run well above those ranges, and the salary guide has the city-level numbers. If you want a band checked against your own scope before finance sees it, the salary benchmark assistant does that for free. Then publish the range. California, Colorado, Illinois, New York, and Washington are among the states that now require one on job postings, and in my experience the engineers you most want scroll past postings that hide it.

iOS Developer Job Description Template

Everything below can go straight into your applicant tracking system. Bracketed text is either a blank only you can fill or my reasoning for the line, and the reasoning shouldn’t survive into the live posting.

Title

[iOS Engineer / Senior iOS Engineer / Staff iOS Engineer, [Payments / Health / Media]] [Use “iOS,” not “Swift.” Swift also runs on servers, and “Swift Developer” draws people who have never pushed a build through App Store Connect. If the role touches watchOS or visionOS in its first year, that belongs in the title too.]

The App and the Team

[Company] builds [one sentence on the product and who uses it: a banking app for 240,000 credit union members / a subscription fitness app / the inventory app our store teams run on]. The iOS app serves [X] people a month, ships [every two weeks / monthly], and supports iOS [16] and later [with a move to iOS 17 planned for Q1]. The codebase is about [70% SwiftUI and 30% UIKit], on the Swift [5 / 6] language mode, with [no Objective-C / Objective-C remaining in the networking layer]. [Candidates read this paragraph twice. Every number in it should still be true on their first day.] You’ll join a team of [N] iOS engineers reporting to [role], working most closely with [design, the backend team, QA, the product owner].

What This Person Owns

• Feature work in Swift across [SwiftUI and UIKit], including screens older than anyone currently on the team
• [If true: our Liquid Glass adoption. The app runs in compatibility mode today, and this role leads the move, custom navigation and tab bar included, before the iOS 27 SDK becomes the App Store minimum.] [Delete this line if it isn’t true. If it is, move it to the top of the list.]
• [The Apple frameworks the app depends on, by name: HealthKit and Core Bluetooth for our connected device / StoreKit 2 subscriptions / AVFoundation playback]
• [Release ownership: signing and provisioning, TestFlight, App Store Connect submissions, and responses to App Review / Feature delivery, with submissions handled by [person or team].] [Choose one. Candidates will ask.]
• Crash triage in [Xcode Organizer / Crashlytics / Sentry], and deciding when a crash spike is serious enough to pause a phased release
• [If applicable: the Swift 6 language mode migration, currently at [warnings on / partway / not started]]

Must Have

• [3+] years building iOS apps in Swift, with at least one you can show us in the App Store or walk us through in detail
• Production SwiftUI [and UIKit, since you’ll work in both every week]
• Swift concurrency in a real app, meaning async/await, actors, and what actually broke when strict checking was turned on
• [Comfort working without the newest APIs when our iOS [16] floor requires it]
• [The frameworks from the list above that are genuinely non-negotiable. Two, maybe three. Everything else moves to Would Help.]
• Debugging on physical devices, including memory and energy problems in Instruments

Would Help

• A shipped design-system migration, whether that was Liquid Glass last year or iOS 7 a long time ago
• Accessibility work with VoiceOver and Dynamic Type. Apple’s Accessibility Nutrition Labels now appear on App Store product pages, and some enterprise buyers check them
• [Your regulated domain, if you have one. An engineer who already knows why protected health information stays out of push notification payloads will save you a quarter.]
• Some Kotlin, if your Android team is weighing Kotlin Multiplatform for shared business logic and the iOS side wants a vote
• Fastlane or Xcode Cloud, for whoever ends up fixing the build pipeline at 6 p.m. on a release day

Where and How Often We Ship

[Fully remote in [these states or time zones] / in the [city] office [X] days a week.] [How often you release, and whether updates go out as phased releases. If engineers carry a pager for production incidents, say how often it actually goes off.] [If the app pairs with physical hardware the engineer needs in hand, say where that hardware lives.]

Pay

[$140,000 to $185,000] in base salary, with [bonus], [equity and vesting schedule], and [benefits]. [State the range in dollars. When Objective-C, a regulated domain, or release ownership pushes the number up, the reason goes here and not on the offer call.]

Asked on Nearly Every iOS Intake Call

We asked for eight years of SwiftUI. Why did nobody qualify?

SwiftUI has only existed since Apple introduced it in June 2019, so nobody on earth has eight years of it yet, and the engineers who notice read the line as proof that no iOS engineer reviewed your posting.

It happens a lot. Usually someone copied the years requirement from a general engineering template and dropped the framework name in beside it. Swift itself dates to 2014. If what you mean is “has built SwiftUI screens that shipped to real users,” write that, and ask for total years on iOS separately.

Is Objective-C still worth listing?

Only if there is Objective-C in the app you’re hiring for, in which case give its rough share and where it lives, because a stray category file and a payments module are very different jobs.

The engineers who are genuinely strong in Objective-C are mostly past the ten-year mark now, and they know what that knowledge is worth. They price it accordingly. Listing it as a nice-to-have on a codebase that contains none attracts nobody in particular. Listing it honestly on a codebase with a lot of it gets you a smaller, more senior, more expensive pool that can actually do the work.

Does the posting need to say anything about AI coding tools?

One sentence on your policy is enough, and candidates have started asking for it, since Xcode 26.3 added agentic coding with Anthropic’s Claude Agent and OpenAI’s Codex built into the IDE.

Apple announced it in February. Some of our clients encourage the tools and want to hear how a candidate reviews generated code before it merges. A couple ban them outright over source-code exposure, which is a legitimate position for a bank. Both positions are fine. Silence isn’t. Either way, an engineer who uses these tools daily would like to know which camp you’re in before the first interview, not after the offer.

Should we mention watchOS or visionOS in case we get to them?

Leave them off unless this person will ship to that platform within a year, because “visionOS a plus” on a phone-only roadmap mostly attracts engineers who want spatial work and leave when it doesn’t come.

CarPlay is the same story, with the added wrinkle that Apple makes you request a CarPlay entitlement before you can ship a CarPlay app at all.

Once the posting is fixed, how long does an iOS search take?

Three to six weeks is typical for mid-level and senior iOS roles, while KORE1’s average across every IT role it fills sits at 17 days.

The iOS figure runs longer because the pool is smaller, and every framework or constraint you name narrows it further. That’s the point of naming them. Budget for it anyway. When a deadline is closer than the search, the setup I suggest most often is a contract iOS engineer for the bounded piece of work, a Liquid Glass adoption for instance, with the direct hire search for the permanent seat opened the same week. Some clients would rather find out on real work first, and contract-to-hire handles that fine.

What should the first phone screen actually check?

Whatever your posting promised, so if it says the role owns App Store submissions, ask about the last rejection they personally answered, and if it mentions Swift 6, ask what they had to change to get there.

The candidate who can tell you which guideline number their app was rejected under has done the job. The one who says “the release team handled that” hasn’t, and you find out before round two instead of after the offer.

If the Req Opens This Week

If I had ten minutes with your draft, I’d go in this order. The Info.plist first, because a compatibility flag decides what the first six months of the job look like. Then the SwiftUI share and language mode, then the deployment target and whether it’s moving, then the two or three Apple frameworks the app can’t live without. After that I’d ask who answers App Review and whose Apple ID owns the developer account. The pay range goes on last. But it goes on.

None of that is about the candidate. It’s all about the app, which is why it so rarely makes it into the posting. The hiring manager knows it so well that it stops feeling like information. It is, though. It’s the only part of an iOS job description a strong candidate can’t read on somebody else’s posting.

If your iOS req is about to go up, or it’s been live a month and the applicants keep missing, start a conversation with our team. We run iOS searches alongside our Android and broader mobile developer staffing desks, for clients in more than thirty metro areas around the country, and a year after placement, 92% of our hires are still there. Hiring for both platforms at once? Pair this page with the Android developer job description template, and use our mobile developer job description template for React Native and Flutter roles.