SwiftUI is the future. UIKit is most of the apps.
Adverts ask for SwiftUI and codebases are usually UIKit, or both at once. An engineer who has only ever written SwiftUI will be slow in the code you have.
Almost every real iOS app is both.
SwiftUI is where Apple is going and it is a pleasure to write. It is also younger than most applications in the store, which means the majority of production iOS code is UIKit, and the majority of new work is SwiftUI screens inside a UIKit application.
That mixed reality is the job. An engineer needs to be comfortable hosting SwiftUI inside a view controller, know when a UIKit component is still the right answer, and understand the navigation model of whichever the application is built around.
We ask what your codebase actually contains before proposing anyone, because “iOS developer” covers people who would be slow in it.
The other half of the role is everything Xcode does not teach you: provisioning profiles and certificates across a team, App Store review and its less predictable moments, staged rollout, and crash reporting with symbolication that works. That is the part which turns a build into an app somebody can rely on.
What we ask an iOS engineer.
Store experience first, architecture second, and a specific question about memory that filters more than it should.
What is on the App Store under your name?
Live links. Building an app and shipping one are different achievements and only one of them is verifiable.
SwiftUI, UIKit, or both?
We are listening for someone who can move between them and knows why the boundary sits where it does in a given codebase.
Where do retain cycles come from here?
Closures capturing self, delegate references. Fundamental, and answered vaguely far more often than it should be.
How do you structure a screen?
MVVM, TCA, plain MVC, any, with a reason. Dogma about one is a worse sign than a pragmatic mix.
How do you handle a rejection?
Everyone who ships has had one. What it was and how quickly it was resolved shows who owns releases.
What breaks on an older device?
Memory pressure, image handling, the oldest OS version supported. The simulator hides all of it.
What an iOS engagement usually also involves.
Being explicit about these changes the profile and prevents a surprise in month two.
| Area | Note | Who |
|---|---|---|
| App Store account and certificates | Yours, not ours. Set up before day one | You, with our help |
| Backend API | Almost always needed alongside | Node or .NET |
| Android as well | Decide early; it changes the whole approach | Android or cross-platform |
| Design | iOS conventions matter and users notice | A designer |
| Push notifications | APNs setup, certificates, and a backend to send them | iOS engineer plus backend |
| Analytics and crash reporting | Configure before launch, not after | iOS engineer |
| Ongoing OS updates | An annual event, not a project | Retainer |
When native iOS is worth two codebases.
We staff Flutter and React Native as well, so this is not a pitch for the more expensive option.
- The app is the business. If the application is the product instead of a channel, the polish difference is worth the second codebase.
- Deep hardware or platform integration. Background processing, complex camera use, HealthKit, widgets, App Clips, CarPlay. Cross-platform frameworks reach these through bridges, badly.
- Performance is a feature. Rendering-heavy applications and anything doing real work on device.
- Platform-native feel is a requirement. Users cannot articulate it and they notice it. On consumer products this is sometimes the whole argument.
- Otherwise, consider cross-platform. For most business applications, one codebase is the better commercial answer— see Flutter and React Native.
- Or ask whether it needs to be an app at all. No hardware requirement and no real need to be in a store means a web application is cheaper on every axis. Asked far too rarely.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring iOS engineers.
Three that come up before rates do.
Should we build native iOS or cross-platform?
Ask what the app has to do, not what it should be written in. If it needs background processing, deep camera work, health data, widgets or CarPlay, native will be cheaper in the end even with two codebases, because cross-platform frameworks reach those through bridges that you then own and debug. If it is screens over an API with some notifications (which describes most business applications), one codebase is the better commercial answer and we would say so. The question worth asking before either is whether it needs to be an app at all, and it is asked far too rarely.
How long does App Store review take?
Usually a day or two now, which is much better than its reputation, and the variance is what should shape your plan rather than the average. A rejection over something unexpected (a privacy label, an account deletion requirement, sign-in options, guideline interpretation) adds days and always arrives at the worst moment. So we submit a build well before the date anybody has promised, and treat the first submission as a review rehearsal, not as the launch. Engineers who have shipped repeatedly build that buffer in without being asked, which is one of the things we listen for.
Do we need someone permanently, or just to build it?
Build and then retain, in most cases, and the retainer is smaller than people expect. An iOS application is not finished at launch: Apple releases a major OS version every year and something always needs attention, dependencies need updating, certificates expire on a schedule that will surprise you, and crash reports need somebody who reads them. That is a few days a month, not a full-time role. What does not work is nobody: an app left untouched for eighteen months becomes a project again instead of a task, and the person who rebuilds the context charges for it.