How to get hired as an iOS developer in 2026-27

The three different jobs hiding behind the title "iOS Developer"

Read the posting before you read the title. Three quite different jobs get advertised under the same two words, they screen differently, and sending the same resume to all three wastes most of your applications.

The first is product iOS at a company whose app is the business: a consumer app, a bank, a retailer, a health app. The codebase is years old, large, and usually a UIKit core with SwiftUI arriving screen by screen. They hire for judgement under constraint: migration without regressions, crash budgets, release discipline, performance on an iPhone several generations old that plenty of their users still carry. The interview will go deep on memory, concurrency, and how you would move a legacy screen across without breaking it.

The second is greenfield or startup iOS, where you are one of one or one of three. SwiftUI throughout, Swift Concurrency throughout, and you own networking, persistence, CI, release, analytics and often the negotiation over the backend contract. They hire for breadth and speed of shipping, and the strongest signal is an app you personally took from empty project to live listing. The interview is often a take-home plus a long conversation about tradeoffs you actually made.

The third is agency, consultancy and contract iOS: several client apps a year, other people's codebases, fixed scope, and heavy emphasis on picking up an unfamiliar project quickly. They hire for range (Objective-C turns up here more than anywhere else), for communication with non-technical clients, and for App Review fluency, because a rejection on a client launch date is their problem. Rates are often hourly and the interview is shorter and more practical.

A fourth category is worth naming because it is frequently mislabelled: postings titled "iOS Developer" that are really cross-platform roles. If React Native, Flutter or Kotlin Multiplatform appears in the first three bullets, the day job is largely TypeScript, Dart or Kotlin with native modules at the edges. That can be a good job, but preparing for it as if it were a native loop is a mistake, and so is dismissing it when the posting says shared logic is moving to Kotlin Multiplatform while the interface stays SwiftUI, which is a common 2026 arrangement and still a native iOS job most days.

• Entry and early-career signals: "0 to 2 years", "under the mentorship of", "contribute to feature work", "learn our codebase", a degree listed as required, no on-call mentioned.
• Mid-level signals: "3 to 6 years", "own features end to end", "participate in code review", "improve our test coverage", a named architecture (MVVM, VIPER, The Composable Architecture, Clean).
• Senior and above signals: "set technical direction for the mobile platform", "own the release process", "modularise the app", "define our SwiftUI migration strategy", plus a design round in the advertised loop.
• Legacy-maintenance signals, which tell you what you will actually do all day: Objective-C, Core Data, storyboards and xibs, CocoaPods, a minimum deployment target several iOS versions behind current, "reduce technical debt".
• Greenfield signals: SwiftUI, Swift Concurrency, Swift Package Manager, SwiftData, "we are rewriting", "0 to 1", "you will make the architecture decisions".
• Cross-platform signals mislabelled as iOS: React Native, Flutter, Kotlin Multiplatform, Expo, "shared business logic", "one codebase, two platforms".
• Hard filters to catch before you apply: "must be authorised to work in the US without sponsorship", "hybrid, three days a week in office" naming a city you are not in, and a required security clearance.
• visionOS in a posting is usually a small part of a wider job. Treat spatial work as a bonus, not as a career plan: the number of openings is tiny next to iPhone work.

What actually gates the job: a Mac, a developer account, and an app with your name on it

Nothing licenses iOS development. There is no board, no exam, no continuing education, and no certificate a hiring manager will ask for. What gates the job instead is a short list of practical requirements that are easy to underestimate.

The hardware gate is real. Xcode is macOS-only, and everything you need to demonstrate the job lives inside it: simulators, Instruments profiling, code signing, archive and upload. Cloud Mac rentals exist and work well for continuous integration, but learning on one is slow and you will be asked to build and run something during an interview. Budget for a Mac before you budget for a course. You also want one physical iPhone, including an older one, because thermal and performance problems only show up on real hardware.

The distribution gate is the Apple Developer Program. A free Apple Account lets you build to your own device with a provisioning profile that expires after about a week, and that is roughly all: no TestFlight distribution to testers, no App Store submission, and no capabilities that need an entitlement, such as push notifications, CloudKit, Sign in with Apple or app groups. The paid programme costs an annual fee Apple publishes on its developer site, and enrolment itself can take days because it involves identity verification, so do not leave it until the week you want to launch. Anyone building a serious portfolio app needs it.

The third gate is not formal at all: code signing and provisioning. Certificates, identifiers, provisioning profiles, entitlements, capabilities, automatic versus manual signing, and what actually breaks when a certificate expires. This is the most common source of panic in a mobile team, it is rarely taught in courses, and being the person who can calmly explain why a build will not install is a disproportionately strong signal in an interview. Learn it by doing one full manual signing setup on purpose.

Degrees sit outside all of this. A computer science degree helps at large employers that run graduate pipelines, and in some visa pathways, and it is close to irrelevant three years in. The substitute is not a certificate: it is an app in the store with real users and a story about what broke.

• Minimum practical setup: an Apple silicon Mac (16GB of memory or more), current Xcode, one modern iPhone and ideally one older device, and an Apple Developer Program membership.
• Enrol in the Developer Program early. Identity verification can take days, and an organisation enrolment requires a D-U-N-S number for the legal entity.
• Know what needs the paid account: TestFlight, App Store submission, push notifications, CloudKit, Sign in with Apple, app groups, and background modes that require entitlements.
• Do one manual code signing setup end to end: create a certificate signing request, a distribution certificate, an App ID, a provisioning profile, then archive and upload a build by hand.
• Learn from primary sources before paid courses: Apple's own Swift and SwiftUI documentation and tutorials, the WWDC session videos for concurrency and SwiftUI performance, Apple's sample code projects, and Stanford's free CS193p lectures. Hacking with Swift is the most-used free written course, and the Swift Forums are where the language's own maintainers answer questions.
• Learn the build-and-release tool names that appear in postings: Xcode Cloud, Fastlane, Bitrise, GitHub Actions on macOS runners, TestFlight, App Store Connect, Swift Package Manager, and CocoaPods for legacy projects.

The portfolio app: the one thing that separates iOS candidates

For most software roles a portfolio is optional. For iOS it is close to decisive, because distribution is public and the artefact is inspectable. A hiring manager can open your App Store listing in ten seconds, see the screenshots, read the reviews, check the update history, download it and use it on their own phone. Almost no other engineering discipline hands the interviewer that much before the first call, and the candidates who ship get called.

It has to be shipped, not a repository. A GitHub link is worth something; a live listing is worth more, because getting through App Review proves a set of unglamorous competences at once: icons and screenshots at the right sizes, a privacy policy, a filled-in privacy nutrition label and privacy manifest, correct entitlements, an age rating, metadata that does not trip the guidelines, and a build that does not crash on launch on the reviewer's device.

Choose the project for the problems it forces you to solve rather than for the idea. A to-do list demonstrates nothing, because it has no network, no concurrency, no error states and no sync. Pick something that forces at least four of these: a real network API with authentication, pagination, offline reading from a local store, background refresh, push notifications, an image pipeline with caching, camera or sensor input, an on-device model, a widget, and an App Intent so Siri can drive it. Then make it genuinely usable: empty states, error states, retry, Dynamic Type, VoiceOver labels, and a dark mode that is not broken.

Write a one-page case study to go with it and keep it where you can paste it. What the app does, who uses it, the architecture in four sentences, the three hardest problems and how you solved them, what you measured (cold launch, crash-free sessions, binary size), and what you would do differently. Interviewers ask "tell me about something you built" and most candidates answer with features. Answer with decisions and failures and you have separated yourself in ninety seconds.

If your best work is under NDA or lives in an employer's App Store account, you are not stuck. Name the app, link the public listing, and state precisely what you owned ("rebuilt the checkout flow in SwiftUI, 11 screens, shipped in version 4.2") without disclosing internals. That is normal and expected. What does not work is a resume full of unnamed "an enterprise iOS application" entries with nothing to open: if everything you have done is invisible, build one small public thing so the interviewer has something to look at.

• Strong portfolio ingredients: authenticated API, pagination, offline cache, background refresh, push notifications, image loading and caching, accessibility, localisation, a widget, an App Intent, an on-device model.
• Weak portfolio ingredients: a to-do list, a weather app with one API call, a UI clone with no data layer, a tutorial project still carrying the tutorial's commit history.
• Ship it properly: a real listing with your own screenshots, a privacy policy URL, a completed privacy nutrition label, and at least two updates in the version history, because the update history shows you maintain software rather than abandon it.
• Put the App Store URL on the resume, the LinkedIn headline and the GitHub profile README, as visible text.
• Keep the repository public if the code is good. Interviewers do read it, and clean commits with meaningful messages and a real test target are read as professional habits.
• If everything is under NDA: link the public listing, name your contribution and its scope, and do not describe internal architecture you were not cleared to describe.
• Install your own app on a spare device before every interview, and check it still launches on the current iOS version. A dead demo is worse than no demo.

The hiring process, stage by stage, and who is on the other side

iOS hiring is run by iOS people more often than general software hiring is run by generalists. Your technical screen is usually another iOS engineer, your loop is usually a mobile team, and your hiring manager has usually shipped through App Review personally. That has two consequences: vague answers get caught immediately, and specific platform detail is appreciated rather than treated as trivia.

Stage one is the recruiter screen, twenty to thirty minutes. They are checking location and work authorisation, salary expectation, notice period, and whether your experience is native or cross-platform. This is where you ask what the loop actually is, because iOS loops vary more than backend loops do. Ask in writing: how many rounds, whether there is a take-home and how many hours it is expected to take, whether the coding round is in Xcode on your machine or in a shared web editor (writing Swift in a browser with no compiler is a different skill, and it is fair to ask), and whether an AI coding assistant is permitted in each round.

Stage two is the technical screen with an iOS engineer. Expect rapid language and framework questions plus a small live exercise. The questions cluster tightly: value versus reference types and when a struct copies, ARC and where retain cycles come from, escaping closures and capture lists, protocols and generics, optionals and when force unwrapping is defensible, the difference between State, Binding, an Observable model and Environment in SwiftUI, and what the main actor is for. Then a short task, usually some version of: parse this JSON into models and show it in a list with a loading state and an error state.

Stage three is either a take-home or a longer live build. A typical take-home is "consume this public API, show a list and a detail screen, handle errors and offline, include tests, and write a short README explaining your choices", scoped at four to eight hours. Reviewers care about error handling, the presence of a seam for testing, the reasoning in the README, and whether you over-engineered. A three-layer architecture with a protocol for everything on a two-screen app reads worse than a plain structure with a stated reason.

Stage four is the loop: a mobile system design round from mid-level up, often an architecture or code-review round where you critique real code, and a hiring manager round about ownership, incidents, release decisions and working with designers. Some teams add a portfolio walkthrough. A growing number add a debugging round, where you are handed a project containing a retain cycle, a main-thread hang or a flaky list and asked to find it with Instruments while narrating what you are doing.

Timelines run two to six weeks, and a take-home adds a week. Agencies and startups move fastest and often decide after two conversations. Larger employers add a hiring committee step after the loop and a levelling discussion that sets your band, which is why the system design round usually matters more to your offer than the coding round does.

• Ask the recruiter, in writing: the full round list, take-home length, whether coding is in Xcode or a browser editor, whether documentation access is allowed, and the AI assistant policy per round.
• Ask what the codebase actually is: the UIKit to SwiftUI split, the minimum deployment target, module count, test coverage, release cadence, and whether they are mid-migration. The answer tells you what the job is.
• Ask about release ownership: who submits, who carries the pager for a bad release, and what their crash-free session rate is. A team that knows its number runs a disciplined shop. A team that does not has told you something.
• Have Xcode open, a scratch project ready and your portfolio app installed on a device before every call. Being asked to share your screen and build something is common.
• If a take-home is longer than eight hours of real work, say so and ask whether a smaller scope or a paired session is acceptable. Reasonable teams agree, and the ones that refuse have told you about themselves.
• Negotiate on the level, not only the number. At large employers the band follows the level, so the design round and the levelling discussion move your pay further than haggling at the end does.

What the technical rounds really test: Swift depth, concurrency and SwiftUI state

iOS interviews are less algorithm-heavy than general software interviews and far more language and framework specific. Large employers still run a standard data structures round, so do not skip it entirely, but the rejection in an iOS loop usually happens on platform depth rather than on a graph problem.

Memory and lifetime come up in nearly every loop. Be able to explain ARC without hand-waving: strong, weak and unowned references, where a retain cycle forms (a closure capturing self held by the object that holds the closure, a delegate declared strong, a parent and child holding each other), what weak self costs you inside a Task, and how you prove a leak rather than guess at it. The complete answer ends with how you found it in the memory graph debugger or with the Leaks instrument, because the practical skill is the point.

Concurrency is the defining 2026 topic and the one most candidates are weakest on. Structured concurrency has been in production for years, and the Swift 6 language mode turned data-race safety into compile-time enforcement, which means real codebases are mid-migration and real interviews ask about it. Know async and await, Task and task groups, cancellation and why it is cooperative, actors and actor reentrancy, the main actor and why a view model usually belongs on it, Sendable and why a mutable class is not, and what the common migration errors actually mean. Know too that later Swift releases added ways to make the migration less painful, including defaulting a module to main actor isolation so that ordinary single-threaded code stops fighting the compiler. The question behind the question is whether you can reason about which code runs where.

SwiftUI questions concentrate on state and identity rather than on layout. Which property wrapper owns the value and which observes it, what the Observable macro changed compared with ObservableObject and published properties, why a list row keeps the wrong data after a sort (identity, not state), when you need an explicit id, what makes a view body re-evaluate and why that is not the same as a redraw, how you keep expensive work out of body, and how you bridge to UIKit with representables when SwiftUI has no answer. Expect at least one question that is really "do you know why this is slow".

UIKit still gets asked, because most money-making apps still contain a lot of it. Cell reuse and what goes wrong without it, diffable data sources and snapshots, Auto Layout priorities and how you debug an ambiguous layout, view controller lifecycle and the difference between viewDidLoad and viewWillAppear for data loading, and navigation. Candidates who have only used SwiftUI get caught here, and candidates who have only used UIKit get caught on the SwiftUI half. Prepare both honestly and say which one you are stronger in.

Then the plumbing: URLSession with async and await, Codable with awkward payloads (snake case, dates, heterogeneous arrays, missing keys), error typing and what you surface to the user, persistence choices (UserDefaults for preferences only, Keychain for secrets, files, Core Data, SwiftData, or SQLite through GRDB) and why, dependency injection without a framework, and testing with Swift Testing or XCTest plus UI tests and snapshot tests. Performance closes it out: Instruments, Time Profiler, hangs and hitches, launch time, and MetricKit for field data.

• Real questions that recur: "What is the difference between a struct and a class here, and why does this one need to be a class?"; "Where is the retain cycle in this snippet?"; "This view updates when it should not. Why?"; "Make this list scroll smoothly with 5,000 items and remote images."; "Why is this code a data race under Swift 6, and what is the smallest correct fix?"
• Concurrency checklist: async and await, Task and detached tasks, task groups, cooperative cancellation, actors and reentrancy, MainActor, Sendable, async sequences, and bridging old completion-handler APIs with continuations.
• SwiftUI checklist: State, Binding, the Observable macro, Environment, view identity and the id modifier, ViewBuilder, preference keys, the cost of GeometryReader, lazy stacks versus List, and UIViewRepresentable.
• UIKit checklist: cell reuse, diffable data sources, Auto Layout priorities and content hugging, view controller lifecycle, container view controllers, and navigation patterns including the coordinator.
• Tooling checklist: Instruments (Time Profiler, Allocations, Leaks, Hangs), the memory graph debugger, Xcode Organizer crash and metric reports, Crashlytics or an equivalent, MetricKit, and the Thread Sanitizer.
• Practise narrating. In a debugging round, saying "my first hypothesis is a retain cycle because this closure captures self, so I will check the memory graph" scores regardless of whether the hypothesis turns out to be right.

The mobile system design round, which is nothing like the backend one

From mid-level upward there is a design round, and candidates who prepare for it with backend material fail it. Nobody wants you to shard a database. The prompt is usually "design the client for a feed", "design offline support for this app", "design an image-heavy browsing experience" or "design a chat client", and the whole round happens on one device with intermittent network, finite battery, limited memory and a binary a user has to download.

The structure that scores well starts with constraints, not components. Ask for the device floor and minimum deployment target, expected payload sizes, whether the data is user-specific or shared, how fresh it must be, whether writes happen offline, and what happens on a conflict. Then draw the layers: networking, a cache and persistence layer, a repository or store that decides what the UI sees, and the UI itself. The sentence the interviewer is waiting for is that the UI reads from the local store and the network updates the store, not that the view calls the API.

Then get specific about the hard parts. Pagination, and what happens when page two arrives after the user has pulled to refresh. Cache invalidation with a stated eviction policy and a size cap. Image loading: downsampling before decode, a memory cache plus a disk cache, prefetching, cancelling in-flight requests on cell reuse. Offline writes: an outbox of pending mutations, idempotency so a retry does not double-post, and a named conflict policy (last writer wins, server wins, or a merge) with a reason. Background refresh and what iOS actually guarantees, which is not much. Push notifications, and silent pushes as a hint rather than a delivery promise.

Finish on what is unique to shipping on a phone, because that is where senior candidates separate themselves. App size, and why download size affects install conversion. A launch time budget. Battery and thermals if you are polling or using the camera. Feature flags and a kill switch, because you cannot roll back a release. Staged rollout. Schema migration for the local store, including what happens to a user who skipped four versions. Analytics and privacy. Testability: where the seams are so this can be tested without a network.

Say the tradeoff out loud, and say what you are not doing. "I would not build full two-way sync for version one. Reads cached, writes queued in an outbox, server wins on conflict, and I would revisit if the analytics show concurrent edits." That one sentence is often the difference between a mid-level and a senior read of the same candidate.

• Open with constraints: device floor, minimum iOS version, payload size, freshness requirement, offline writes, conflict policy, and who else is editing the data.
• Name the layer boundaries explicitly, and state that the UI reads the local store rather than the network.
• Have a prepared answer for images: downsample before decode, memory plus disk cache with a size cap, prefetch ahead of the scroll, cancel on reuse.
• Have a prepared answer for offline writes: an outbox with idempotency keys, retry with backoff, and a conflict rule you can defend.
• Close on release safety: feature flags, a kill switch, phased rollout, local schema migration, and a crash-free session target you would hold the release to.
• Keep the arithmetic simple and say it out loud. Decoding a full-resolution image into a cell a few hundred points wide wastes memory and decode time, and downsampling to the displayed size fixes both.

Shipping and operating: the half of the job nobody prepares for

iOS differs from web engineering in one structural way that shapes every interview question about judgement: you cannot take a release back. A web team rolls back in minutes. A mobile team ships a build, discovers a crash, writes a fix, submits it, waits for review, and then waits for users to update. That is why experienced iOS interviewers ask about process at all, and why a candidate who has felt it answers differently.

App Review is a real part of the job. Apple publishes current review timings and most submissions clear in a day or two, but the outcome is never guaranteed and the common rejection reasons are learnable: a crash on the reviewer's device, a missing or broken demo account, inaccurate privacy disclosures, requesting a permission without a clear in-context explanation in the usage description string, requiring sign-in for features that do not need an account, payment flows that do not follow Apple's rules for the category, incomplete metadata, and user-generated content with no moderation or reporting path. Knowing that expedited review exists and when it is appropriate to ask for it is a senior detail worth having.

Privacy obligations are now mechanical gates on submission rather than a policy conversation. You declare data collection in the privacy nutrition label, you ship a privacy manifest for your app and your third-party SDKs, and certain APIs require you to declare an approved reason for using them. Third-party SDKs must carry their own manifests and signatures, which is why "we audited and removed four SDKs" is a credible resume line. Treat the specifics as things to verify against Apple's current developer documentation before you quote them in an interview, because the requirements have been tightened more than once.

Distribution rules themselves have been in flux, and this is where you should be most careful about repeating anything you read. Regulatory action in the European Union has forced alternative distribution and payment arrangements on iOS, and separate litigation in the United States changed what apps may tell users about purchasing outside the App Store. The direction of travel is clear and the details have changed repeatedly, including after most published guides were written. If a company's business depends on it, describe the shape of the obligation and say you would check the current position rather than quoting a rule or a date. That is also the honest answer in the room.

Operationally, the numbers a mobile team actually watches are crash-free session rate and crash-free user rate, hang rate and launch time, adoption per version, app size, and store rating trend. Know where they come from: Xcode Organizer, MetricKit for field performance, and a crash reporter such as Crashlytics or Sentry. If you have ever triaged a production crash from a symbolicated stack trace and shipped the fix, that story belongs in your interview with the numbers attached.

• Know the release vocabulary: TestFlight internal and external testing, phased release, expedited review, a kill switch and server-driven feature flags, and a minimum supported version check.
• Common App Review rejection causes to be able to name: crash on launch, a broken or missing demo account, inaccurate privacy disclosure, a permission prompt with no explanation, metadata problems, and user-generated content without reporting and blocking.
• Know the privacy mechanics by name: privacy nutrition labels, the app privacy manifest, required-reason API declarations, SDK signatures, and App Tracking Transparency.
• Know the operational metrics and the tools: crash-free sessions, hang rate, launch time, app size, version adoption; Xcode Organizer, MetricKit, Crashlytics or Sentry.
• Be able to tell one production incident story: what broke, how you found it, what the fix was, how fast it shipped, and what you changed so it could not happen silently again.
• On anything regulatory, state the obligation and say the current position needs checking. Confidently quoting an out-of-date rule in an interview is worse than saying you would verify it.

The resume, the search, and where the iOS jobs actually are in 2026-27

Start with the market, honestly. Native iOS hiring is smaller than it was at the 2021 peak. Companies consolidated mobile teams and some moved shared logic to cross-platform stacks, and the effect is fewer openings skewed toward mid-level and senior, with entry-level the hardest segment. That is not a reason to avoid the field. It is a reason to be specific: the demand that remains is concentrated in companies where the app is the product or a regulated channel, and those companies hire slowly and pay for depth.

Where the openings cluster: consumer apps with large install bases, banks, insurers and brokerages, health and telehealth, retail and quick-service restaurant apps, travel and transport, media and streaming, industrial and field-service apps that use the device's sensors and camera, and the agencies serving all of the above. Hardware and device companies hire iOS engineers to build companion apps, which is a steady and often overlooked seam. Anything that depends on on-device capability (camera, sensors, local models, HealthKit, CarPlay) is hired native, because cross-platform cannot reach it cleanly.

Now the resume. The header carries your name, location, work authorisation if it helps, contact, GitHub, and at least one App Store URL as visible text. Each role gets a one-line context sentence saying what the app was and its scale, then bullets that are decisions with numbers: what you changed, what moved, by how much. "Migrated 23 screens from UIKit to SwiftUI across three releases with no increase in crash rate" tells a hiring manager more than a paragraph of adjectives.

What gets ignored or actively hurts: skill bars and percentage ratings, a list of forty frameworks (naming MapKit, StoreKit, HealthKit, ARKit and CoreMotion when you touched each once reads as padding and invites a question you cannot answer), "passionate about the Apple ecosystem", an objective statement, and a two-page resume for three years of experience. Avoid claiming SwiftUI and UIKit and React Native and Flutter and Kotlin Multiplatform on one line: it reads as unfocused, and the follow-up question will find the gap.

On applying: this is a small world, and referrals matter more than in larger disciplines. The iOS community is unusually public, which works in your favour. A specific, non-generic message to the mobile lead at a company whose app you have actually used, naming one concrete thing about the app, works better than a hundred applications. So does visible work: a Swift package other people depend on, a well-written bug report with a reproduction case filed through Apple's Feedback Assistant, a meetup or conference talk, a write-up of a real fix. Local iOS meetups, the Swift Forums, and the iOS newsletters that list jobs are where those conversations start, and interviewers do notice. It is a legitimate substitute for the referral you do not yet have.

• Resume header: name, location, work authorisation if relevant, email, GitHub, and the App Store link as plain visible text.
• One line per role setting the scale before the bullets: what the app is, roughly how many people use it, its rating, how large the codebase is and in what languages.
• Metric vocabulary that reads as real: crash-free sessions, cold and warm launch time, hang rate, download size, memory peak, scroll frame drops, version adoption rate, rating movement, conversion on a flow you own.
• Keep a short, honest skills line: Swift, SwiftUI, UIKit, Swift Concurrency, Combine if you use it, Core Data or SwiftData, URLSession, XCTest or Swift Testing, Instruments, Fastlane or Xcode Cloud, plus any on-device ML frameworks you have shipped with.
• Target companies whose apps you use and can talk about concretely. Criticising a public app in a first message is risky; naming something it does well and one thing you were curious about is not.
• Visible community work substitutes for a referral: a maintained Swift package, a reproducible bug report through Apple Feedback Assistant, a meetup talk, a technical write-up about a real fix.
• Apply to roles asking for a year or two more experience than you have if the shipped app backs you. The market skews mid-level, and the posting's number is a wish, not a filter the engineers enforce.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• iOS Developer
• iOS Engineer
• Mobile Engineer
• Mobile Developer
• Senior iOS Engineer
• Swift
• SwiftUI
• UIKit
• Objective-C
• Xcode
• Xcode Cloud
• App Store Connect
• TestFlight
• Apple Developer Program
• Code signing
• Provisioning profiles
• Entitlements
• Swift Package Manager
• CocoaPods
• Fastlane
• Swift Concurrency
• async/await
• Actors
• MainActor
• Sendable
• Swift 6
• Structured concurrency
• Task cancellation
• Combine
• ARC
• Retain cycle
• Memory management
• Value semantics
• Protocol-oriented programming
• Generics
• Property wrappers
• Observable macro
• View identity
• MVVM
• VIPER
• Clean Architecture
• The Composable Architecture
• Coordinator pattern
• Dependency injection
• Modularisation
• URLSession
• Codable
• REST API
• GraphQL
• WebSocket
• Offline-first
• Caching
• Pagination
• Image caching
• Core Data
• SwiftData
• SQLite
• GRDB
• Keychain
• UserDefaults
• CloudKit
• Background tasks
• Push notifications
• APNs
• Silent push
• Deep linking
• Universal Links
• Widgets
• WidgetKit
• App Intents
• SiriKit
• Shortcuts
• Live Activities
• ActivityKit
• StoreKit
• In-app purchase
• Sign in with Apple
• HealthKit
• MapKit
• AVFoundation
• Camera
• Core Location
• CarPlay
• watchOS
• visionOS
• Accessibility
• VoiceOver
• Dynamic Type
• Localization
• XCTest
• Swift Testing
• UI testing
• Snapshot testing
• Unit testing
• Test-driven development
• Instruments
• Time Profiler
• Memory graph debugger
• Thread Sanitizer
• MetricKit
• Crashlytics
• Sentry
• Crash-free sessions
• Launch time optimisation
• App size reduction
• Performance profiling
• CI/CD
• GitHub Actions
• Code review
• Feature flags
• Phased release
• App Review Guidelines
• Privacy manifest
• Privacy nutrition labels
• App Tracking Transparency
• Core ML
• Core ML Tools
• Vision framework
• Natural Language framework
• Create ML
• Neural Engine
• On-device machine learning
• Model quantisation
• Apple Intelligence
• Foundation Models framework
• Guided generation
• On-device LLM
• AI-assisted development
• Kotlin Multiplatform
• React Native
• Flutter
• Firebase
• Agile
• Scrum

Mistakes that cost people this job

Questions people ask