A native iOS app, built in Swift and taken through App Store review

What this actually solves

Three reasons bring a business to a native iPhone build, and each of them is specific enough to test. The first is capability: the app needs something Apple gives its own platform first and gives it properly — fine-grained camera control, Apple Pay, HealthKit data, secure enclave authentication. The second is feel under pressure: trading, banking, a media product where the app is the product, and where a dropped frame during a scroll is a commercial problem rather than a cosmetic one. The third is audience. In parts of the US and the Gulf, a business genuinely does find that almost every customer worth reaching is on an iPhone, and paying to support a platform nobody in that market uses is waste.

The counterpoint matters just as much, and we would rather raise it in the first call than after a contract is signed. If none of those three describes you, native iOS is probably the more expensive way to get the same outcome, and a single cross-platform codebase will put a comparable product on both stores. Where you say native Swift and mean it, there is almost always a reason underneath — an existing Objective-C or Swift codebase to extend, or specific hardware work — and we will ask what that reason is. It changes the estimate.

One more thing worth stating plainly, because it explains where the money goes. Writing Swift is a minority of this job. The rest is Apple's rules, Xcode's less obvious failure modes, memory and scroll behaviour measured in Instruments rather than guessed at, and knowing which approach is going to be deprecated in the next release. That knowledge is what separates an app that survives its second year from one that has to be rebuilt.

What we do, and in what order

1. Scoping call, and the list of what version one will not contain. That second list is the useful one. It is written down, it goes into the specification, and it is usually longer than the feature list. Two to three days.
2. Specification, screen list, and accounts opened in your name. Apple Developer Programme enrolment is $99 a year on your card. An organisation account needs a D-U-N-S number and Apple's verification, which can take anywhere from a couple of days to a fortnight. We start this in week one specifically so that it is never the thing holding up a finished build. One to two days of our time, then Apple's clock.
3. Screen map and data model, approved in writing. Every screen named, every route between them drawn, and the underlying entities agreed before any of it is built. Approval can be a message, but it exists. Three to five days.
4. Build, screen by screen, on a real device. SwiftUI or UIKit depending on what the app has to do and how far back it has to support. Screens without data first, then screens that read, then screens that write. Instruments used for memory and scrolling rather than a subjective judgement about whether it feels fast. Six to eighteen weeks depending on scope.
5. TestFlight beta with your own people. Real phones, real network conditions, real opinions arriving while changes are still cheap. One to two weeks, running alongside the build.
6. Store assets and the paperwork. Icon, screenshots at each required size, listing copy, a live privacy policy URL rather than a PDF, App Privacy answers, content rating, export compliance, and a working demo account in the review notes. This is a day of work that people budget an hour for. Two days.
7. Submission, review, and answering a rejection. We fix and resubmit rather than argue. One to two weeks, and this is the part nobody controls.
8. Handover. Account ownership confirmed, certificates and profiles documented, and a written page on how the next release actually goes out. One day.

What moves the price

The range is $8,000–$60,000 across 2–6 months, and three things decide where in it a particular project lands.

How much sits behind the screens. An app reading from an existing API is a different job from one where the data model, the backend and the admin side all have to be built alongside it. Screen count is the honest unit here, and we price by it.

Whether the data is regulated. Health records and anything touching payments or financial position bring audit requirements, tighter review scrutiny, and a longer list of things that must be demonstrably correct rather than merely working. That is real work, and it belongs at the top of the range.

New build or inherited codebase. Extending someone else's app is not cheaper than starting fresh, and it is often dearer. An older codebase with no tests and deprecated APIs has to be understood before it can be safely touched, so we sell a short paid review of the existing code before quoting the work itself.

What usually goes wrong

The developer account is left until the end. The team builds for two months, gets to submission week, and discovers Apple's organisation verification has not started - or has started and needs a D-U-N-S record the business does not have. The build is finished and the app cannot go anywhere. This is why enrolment is step two here and not step nine.

Guideline 5.1.1 catches the app on its first submission. If people can create an account inside the app, Apple requires that they can delete it from inside the app too. It has been mandatory since 2022, it is one of the most common reasons a first submission comes back, and it is roughly two hours of work if you know about it in advance and a lost week if you do not.

The simulator is mistaken for testing. The simulator runs on desktop hardware with desktop memory and a perfect network. It will not show you memory pressure on an older device, it will not reproduce what happens when the app is backgrounded and the system reclaims it, and it will not find the bug that only appears on one particular model. Every build here is exercised on physical hardware before it is called finished.