Hire iOS Developers

Native iOS earns its place where the app is the product rather than a companion to it, or where it depends on hardware and platform features that cross-platform layers reach late — precise location, background processing, widgets, secure enclave work, the newest system frameworks the week they ship.

On this platform the build and release process is part of the engineering, not an afterthought handled by whoever has the certificate. More iOS delivery slips to signing, provisioning and review than to code, and an engineer who has not owned that half has only done part of the job.

Swift 6 concurrency is the current dividing line

Strict concurrency checking turns data races into compile errors, which is the right direction and a genuinely large migration. A codebase adopting it produces a wave of similar errors about actor isolation and sendability, and there are two ways through.

The wrong way is to make the errors go away — marking types as unchecked, annotating everything onto the main actor, or lowering the checking level per file and forgetting. The right way is slower: for each type, decide whether it is genuinely shared, and either make it immutable, give it an actor, or confine it. Silencing the compiler is not the same as making the code thread-safe, and the difference only shows up under load on a device.

Ask a candidate how far through this they are on an existing codebase. It separates engineers keeping up from engineers coasting more reliably than any framework question.

SwiftUI and UIKit, described honestly

Almost every real application is a mixture, and the interesting question is where the boundary sits. SwiftUI is excellent for forms, lists, settings and anything that mirrors state. UIKit still wins where you need precise control over a collection view’s layout and lifecycle, complex text handling, or behaviour on older systems.

The failure we see most often is a SwiftUI view that has become a controller — network calls, navigation decisions and formatting inside a body that the framework may evaluate at any time. Views are a function of state, and code with side effects in one is code whose execution count is not defined.

Release engineering, in specifics

A few things we have learned the hard way running store pipelines.

Automated version bumping through Apple’s own command-line tool rewrites the property list and replaces the build-setting reference with a literal number, which quietly breaks the indirection for every later release. Editing the project file directly is uglier and correct.

App Store Connect rejects a submission with no release notes, while the automated metadata step will skip notes entirely when metadata upload is disabled. The fix is two phases: upload the binary without submitting, set the notes through the API, then submit without re-uploading.

A pipeline whose lanes all publish to the live store should say so at the top of the file, and should verify that the production environment is the one baked into the build before it archives. Shipping a store build pointing at a staging host is the worst failure mode available here, because the store’s review latency is also your rollback latency.

And expect the toolchain itself to break you. A pinned C++ dependency that predates stricter compiler rules will stop building when Xcode updates, and the practical answer is a scripted patch applied after dependency installation rather than a note in a readme.

The rejection reasons that are avoidable

Missing or empty purpose strings. An app that requests a permission on launch with no context. A sign-in wall in front of content that does not need an account. A privacy manifest that does not match what the app and its dependencies actually collect.

None of these are judgement calls by a reviewer; they are checklist items, and every one of them costs a review cycle. Anyone who has shipped seriously has a story about one.

Where native iOS is the wrong choice

Where the same product must exist on Android with identical behaviour and one team maintains both. Where the application is mostly content and a mobile web experience would serve it. And where the budget cannot absorb a review cycle in the release plan — the store is a dependency you do not control, and a fixed launch date with no slack in front of it is a risk taken rather than a plan.

What we interview for

Ask what they did when an app was rejected, because everyone who has shipped seriously has been. Then ask how they are handling Swift 6 concurrency in an existing codebase. Comfort with UIKit still matters too, as almost every real application is a mixture.

One more: how does a crash reported by a user get to a stack trace you can read. Symbolication, build archives and where they are kept are a boring answer that only comes from having needed it.