How to assess · For hiring teams
How to Assess Swift / iOS Skills When Hiring
The test formats that actually work for Swift / iOS, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess Swift / iOS with a task, not a conversation: fix a small broken app, build a screen from a spec, ai-scored assessment (e.g. cohesyve) or architecture conversation. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Keeps the main thread free: network and heavy work off it, UI updates on it, and knows how to prove it
- Manages memory deliberately: understands ARC, spots retain cycles, uses weak and unowned with reasons
- Models state so there is one source of truth, whether in SwiftUI, MVVM or another pattern
- Uses Swift's type system — enums with associated values, optionals, protocols — to make invalid states impossible
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
iOS development has changed enough in the last few years that a candidate's experience may be in a different framework from the one your app uses: UIKit or SwiftUI, completion handlers or async/await, storyboards or code. What does not change is the judgement underneath — how state flows through the app, how work is kept off the main thread, how memory is managed, and how the app behaves when the network is bad. This page covers how to assess Swift and iOS for mobile roles: language fluency, app architecture, concurrency, UI implementation, and the practical experience of shipping to the App Store.
Why Swift / iOS is worth testing
iOS defects are visible to users immediately: a frozen UI, a crash, a screen that shows stale data, a memory leak that grows until the app is killed. They come from the same handful of causes — main-thread blocking, retain cycles, state that lives in too many places — and a strong developer avoids them by habit. Testing shows whether a candidate has those habits, and a résumé full of shipped apps does not.
What strong Swift / iOS looks like
- Keeps the main thread free: network and heavy work off it, UI updates on it, and knows how to prove it
- Manages memory deliberately: understands ARC, spots retain cycles, uses weak and unowned with reasons
- Models state so there is one source of truth, whether in SwiftUI, MVVM or another pattern
- Uses Swift's type system — enums with associated values, optionals, protocols — to make invalid states impossible
- Handles async with structured concurrency or a disciplined alternative, and handles cancellation
- Builds UI that adapts to size classes, dynamic type and accessibility
- Has shipped: knows provisioning, signing, review guidelines and crash reporting
Ways to assess Swift / iOS
Fix a small broken app
Provide a small project with a retain cycle, a network call on the main thread, and a view that shows stale data after an update. Ask the candidate to find and fix each and explain the mechanism.
Pros
Cons
Best for Mid and senior iOS roles.
Build a screen from a spec
Ask for a list-and-detail screen that loads from an API, handles loading and error states, and supports dynamic type. Two to three hours capped.
Pros
Cons
Best for Any level; the spec scales it.
AI-scored assessment (e.g. Cohesyve)
Generate an iOS task from the job description — an architecture question, a concurrency review, a state-management design — with a rubric. Each candidate receives a different variant; reasoning is scored with the code.
Pros
Cons
Best for Screening before pairing.
Architecture conversation
Describe a feature with offline support and background sync and ask how they would structure it.
Pros
Cons
Best for Senior and lead mobile engineers.
Cohesyve
Run a Swift / iOS assessment on your next opening
Cohesyve generates a unique Swift / iOS task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Concurrency and the main thread
Whether the UI stays responsive.
Memory
Whether they understand ARC in practice.
State and architecture
Whether state has one home.
UI and shipping
Whether the app is complete and shippable.
Sample Swift / iOS questions
What is a retain cycle, and how do closures cause them?
EntryLook for Two strong references; `self` captured in a closure held by `self`; `[weak self]` with the trade-off explained.
Why must UI updates happen on the main thread, and how do you get there from a background task?
EntryLook for UIKit and SwiftUI are not thread-safe; `MainActor` or `DispatchQueue.main`; how to verify.
Model the state of a screen that loads a list, can be empty, can fail, and can refresh.
MidLook for An enum with associated values; one source of truth; the view derives from it.
A view shows stale data after the user edits it elsewhere. What went wrong architecturally?
MidLook for State duplicated across screens; fix by a shared store or observable model.
Design offline support for a notes app with sync.
SeniorLook for Local persistence as the source of truth, a sync queue, conflict handling, and what the user sees while offline.
Red flags
- Cannot explain a retain cycle
- Does network work on the main thread and does not know it
- State lives in view controllers and is copied between them
- Has never used Instruments
- Has not shipped through App Review
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Concurrency and responsiveness | 25% | Main thread is protected; async is structured and cancellable. |
| Memory management | 20% | ARC is understood; leaks are found and fixed. |
| State and architecture | 25% | One source of truth; screens derive from it. |
| UI quality | 20% | Adaptive, accessible, handles every state. |
| Shipping experience | 10% | Knows the path to the store and what breaks it. |
Mistakes hiring teams make
- Testing UIKit trivia when the app is SwiftUI, or vice versa
- Not planting a threading or memory bug — they are the real ones
- Accepting a screen that ignores error and empty states
- Ignoring accessibility
- Hiring on App Store credits without checking the fundamentals
Roles that need Swift / iOS
Common questions
Should I test UIKit or SwiftUI?
The framework your app uses, primarily. The judgement — threading, memory, state — transfers; the APIs do not. A strong UIKit developer can learn SwiftUI, but test the fundamentals rather than assuming.
What is the best single iOS screening question?
Show a closure that captures `self` strongly inside a class and ask what happens. Retain cycles are the fastest test of whether someone understands ARC.
How do I assess iOS without Xcode in the loop?
Architecture and state design questions work on paper, and code review of a small diff tests memory and threading knowledge. Confirm build-and-run with finalists.
How much should a junior iOS developer know?
Swift optionals and enums, the main-thread rule, basic ARC, one architecture pattern, and how to build a screen with loading and error states. Offline sync and advanced concurrency are mid-level.
Cohesyve · Skill assessments for hiring
Test Swift / iOS before the first interview
Generate a role-specific Swift / iOS assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog