A guide to hiring an Objective-C developer
Objective-C is the language Apple used to build iPhone, iPad and Mac apps for many years, before Swift arrived. Plenty of apps in the App Store still run on it, and it works well beside Swift in the same project. Teams that look for an Objective-C developer usually have a real app, real users and a code base with history. The sections below explain the work, the signs of a strong candidate and the habits that make remote work go well. They are written for founders and team leads who want their app to stay reliable.
What older Apple code looks like
Objective-C adds message passing to the C language. You will see square brackets for method calls, header and implementation files, categories that add features to existing classes and blocks for callbacks. Many projects also use patterns from the early days of iPhone development, such as delegates on every screen and large view controllers. None of this is wrong. It is simply a style, and a good developer reads it with respect for the reasons behind it.
The jobs people hire for
One common job is care. A new iOS release changes how a screen looks, a crash report appears or an SDK needs an update. Another is features. The business wants a new flow, a payment option or a better settings screen, and the cleanest way is to add it in Swift beside the old code. A third is gradual modernizing, where the oldest classes are replaced one by one while the app stays on sale.
Where an Objective-C developer fits among other roles
An iOS developer builds apps for iPhone and iPad, usually in Swift. An Xcode developer looks after builds, signing and releases. An Objective-C developer is the person who knows the older layer well, which makes them the strongest bridge between the original app and its next version. On many teams one person plays two of these roles.
When an Objective-C developer makes sense
- Your app was started years ago and a large part is still Objective-C.
- The developer who wrote it has left and nobody wants to touch the old classes.
- An update to iOS or Xcode broke your build or changed how screens look.
- You plan to move to Swift and want a safe order of work.
- Crashes happen in code that your current team does not fully understand.
If your app is brand new and written in Swift, a Swift specialist may be a better start. A developer who says so before you spend money is a good sign.
Look at how they read unfamiliar code
Share a class from your app, with private details removed, and ask what the candidate notices. Strong people find ownership problems, long methods, hidden dependencies and risky threading in a few minutes. They ask what the screen is for before they suggest changes. That habit keeps a small fix from turning into a week of new bugs.
Reading an Objective-C developer’s background
Request examples of apps they maintained, and of the problems they solved after an iOS release. Good answers describe a cause and a fix, for instance a crash from a changed API and the small change that removed it. Treat with care a background that only lists app names. Having worked on an app is easy to claim, while explaining what you changed and why shows real contribution.
Questions to ask in interviews
- How do you find the cause of a crash that only a few users report?
- What would you check before replacing an old class with a Swift version?
- How do you spot and fix a retain cycle?
- How do you set up a project so Swift and Objective-C can call each other?
- What do you do when a third party SDK stops being updated?
Good answers are specific and include real cases. Be wary of anyone who only describes the case where everything works.
Try a paid mini project
Give each finalist one small piece of real work from your own project. Good examples are a crash from your latest report, a screen that looks wrong on newer devices, or one older class covered by tests and then moved to Swift. Pay for the time spent. Then compare how the person reads the existing code, how careful the changes are and how well they explain their choices.
Agree how the app is released
Apps are judged in public, so agree on the release routine early. Decide who owns the Apple developer account, who submits builds and how a bad release is rolled back. Ask for a short note with every change that says what moved and why. Keep the code and the accounts under logins your company controls.
Working with your team
Walk your developer through how real people use the app, which devices matter most and which screens earn the money. A brief weekly meeting and one shared list of tasks keep the whole team on the same page. Share the parts you are afraid to change early, because they tend to set the real size of the job.
Common mistakes
- Starting a rewrite before anyone has listed what the app does.
- Changing old classes that have no tests.
- Waiting for a new iOS release to land before looking at the warnings.
- Letting only one person hold the developer account and the signing keys.
Looking at a wider role? Take a look at our iOS developers for full app work, or our UIKit developers for screens and navigation.