Cohesyve · Practice for candidates
Going for an iOS Developer role? Find out how you'd actually score.
Run an iOS Developer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
Overview
An iOS assessment usually gives you a small app and a scoped change: build a screen against a provided API, fix a bug, or make an existing view behave correctly. What is being measured is not Swift trivia but whether your code holds up under real conditions — a slow response, a cancelled task, a memory cycle, a device size you did not design for. This page covers the formats, the marking, and how to prepare.
Why employers assess this role
Apple's frameworks are opinionated, and a candidate can be productive against a tutorial while still producing retain cycles, main-thread stalls, and view models that fall apart under concurrency. Employers assess before interviewing because those problems are invisible in conversation and expensive once the code is in a shipped build reviewed by App Review.
What gets tested
The format
Duration
60–120 minutes
Question types
- Build a screen against a supplied endpoint
- Fix a defect in a provided project
- Code reading and critique
- Short written reasoning about design trade-offs
Levels
Entry · Mid · Senior
What you'll be asked to do
Build a screen from a brief
A short spec and often a JSON endpoint. The brief tends to leave out the failure and empty cases on purpose, to see whether you notice.
- •Build a list that fetches and decodes items and shows a retry on failure
- •Implement a detail view pushed from a list with correct navigation state
- •Build a form with validation that disables submission until it is valid
Manage state and data flow
Assessors look at where state lives, who is allowed to change it, and whether the view rebuilds for the right reasons.
- •Move logic out of a view into an observable model and justify the split
- •Ensure a view does not re-render on every keystroke of an unrelated field
- •Share one piece of state between two screens without duplicating it
Handle concurrency correctly
The distinguishing area at mid and senior level. A naive implementation works once and misbehaves when the user navigates away mid-request or types quickly.
- •Cancel an in-flight request when the view disappears
- •Ensure UI updates happen on the main actor without scattering dispatch calls
- •Prevent two overlapping searches from rendering results out of order
Diagnose a defect you did not write
A crash, a leak, or a layout that breaks on one device class. You are marked on how you narrow it down as much as on the fix.
- •A view controller is never deallocated; find the cycle
- •A crash occurs when force-unwrapping a decoded field
- •A layout that looks correct on a large device clips on a smaller one
Cohesyve for candidates
Practise an iOS Developer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Sample tasks — and what strong looks like
Build a search screen that queries a provided endpoint as the user types and displays the results.
MidWhat strong looks like: Debounces the input, cancels the previous task so responses cannot land out of order, and shows distinct loading, empty and error states. Weak submissions fire a request per keystroke and render whichever response returns last, which looks fine on a fast connection and is wrong on a slow one.
A supplied view controller is never released after it is dismissed. Find and fix the cause.
MidWhat strong looks like: Uses the memory graph or instruments rather than guessing, identifies the strong reference held by a closure or delegate, applies weak capture at the right place, and explains why the cycle formed. Weak answers add [weak self] everywhere until the symptom disappears.
Decode a supplied JSON payload that contains optional fields, an inconsistent date format, and one field that is sometimes a string and sometimes a number.
EntryWhat strong looks like: Models the awkward field explicitly rather than force-unwrapping, uses a custom decoding strategy for the date, and fails with a message that names the offending field. Weak answers crash on the first payload that deviates from the sample.
Take a 400-line view file and restructure it into something you would be comfortable maintaining, then justify the boundaries you drew.
SeniorWhat strong looks like: Splits along real responsibilities — presentation, state, data access — extracts reusable pieces where they are genuinely reused, and gives a reason for each boundary. Weak answers produce a scatter of tiny types with no clear ownership.
How to prepare
- #1
Practise against a timer and finish something, because pacing rather than knowledge is the usual reason a competent candidate fails.
- #2
Rehearse the failure paths specifically — a request that fails, a payload that is empty, and a user who leaves the screen mid-load — as these are the most heavily marked and most often skipped.
- #3
Get comfortable with task cancellation and the main actor so that concurrency correctness is instinct rather than something you reason about under time pressure.
- #4
Practise using the memory graph debugger on your own projects until finding a retain cycle takes minutes rather than the whole assessment.
- #5
Write one unit test over your view model in every practice run, since a testable state layer is a scoring criterion in most rubrics.
- #6
Do a complete mock end to end, including the written reasoning, rather than a set of disconnected exercises.
Common mistakes
Force-unwrapping decoded values and shipping a crash on the first payload that differs from the sample.
Putting networking and business logic directly in the view so nothing can be tested.
Leaving requests running after the view has gone, then updating state that no longer matters.
Ignoring the empty and error states entirely and demonstrating only the happy path.
Hard-coding sizes so the layout breaks on a device class other than the simulator that was open.
Submitting without a clean build, leaving warnings and unused code in place.
How it's scored
| Criterion | What strong looks like |
|---|---|
| Does it work | The stated requirements function on a real run, including the edge cases the brief names. This is weighted above everything else. |
| State and data flow | State has one owner, views observe rather than duplicate it, and updates happen for identifiable reasons. |
| Concurrency safety | Work is cancelled when it stops mattering, UI updates occur on the main actor, and overlapping requests cannot render out of order. |
| Memory and resource handling | No retain cycles, no unbounded image or data caches, and objects deallocate when their screen is dismissed. |
| Testability and reasoning | Logic sits somewhere a test can reach it, assumptions about the brief are stated, and trade-offs are explained rather than implied. |
Frequently Asked Questions
Will the assessment be in SwiftUI or UIKit?
Normally whichever the employer's codebase uses, and it is usually stated up front. Where the choice is yours, take the one you are faster in — the rubric is generally about state, concurrency and correctness rather than the view framework.
Am I allowed to use third-party libraries?
Often yes, but reach for them sparingly. Pulling in a networking library for two requests invites the question of whether you can write the underlying code, and a large dependency list on a short task tends to read as avoidance.
Do I need to handle every device size?
You need the layout to hold on a small phone and not break on a large one. Full iPad and accessibility-size support is only expected when the brief asks for it, though respecting Dynamic Type costs little and is noticed favourably.
What if I cannot finish in the time given?
Make what exists correct and leave a short note describing what remains and how you would approach it. A working subset with clear reasoning consistently outscores a fuller submission that crashes.
Is it worth practising a scored iOS task first?
It is the fastest way to find out where you actually lose marks. Cohesyve includes three free assessments with a full report and a learning pathway, so you can rehearse the format before it counts.
Practise another role
Cohesyve · Practice for candidates
Practise an iOS Developer assessment now — free.
Three free scored assessments, a full report on every run, and a learning pathway built from what you got wrong. No card required.
3
free assessments
$0
no card required
Full
scored report every run
Every
question type included
3 free assessments · No card required · Pro from $16/mo
For hiring teams
Hiring for an iOS Developer role? See how your applicants perform before you spend interview time.