What an iOS app costs to build

Apple sells a handful of phones at a time and supports them for years. A current iOS project targets something like a dozen active screen sizes across iPhone and iPad, plus the two most recent major OS versions, because Apple’s users move to new releases quickly. The large majority are on a new version within a year of its release. That is a test plan one person can hold in their head, and it is the platform’s one real cost advantage.

The saving shows up in QA, and in the number of device-specific defects that reach your customers instead of your test pass. Engineering is unchanged, and the whole thing is worth a few percent of the total. Useful on a tight budget. Thin grounds for abandoning half your audience.

Review is fast now by historical standards, and most submissions clear within a day or two. The expensive case is the tail. A rejection over a privacy disclosure, a missing account deletion path, a permission prompt that does not explain why it is asking, or a demo account that quietly expired costs a full round trip, and round trips land on the launch date rather than the invoice.

2–3 weeks

Kickoff, your own review cycles, and the store

1–2 days

A submission that clears review first time

The same applies to updates. A critical bug fix goes out when review says so, and then when users update. On iOS most people update quickly, which takes care of the second half of that problem. The first half stays Apple’s to decide.

A handful of platform requirements are mandatory, small individually, and consistently missing from budgets written by people who have not shipped on iOS recently.

• 01

  If your app lets people create an account, it must let them delete it from inside the app. Emailing support does not count. That is a flow, a backend endpoint, and a set of decisions about what deletion means for data other people can see.

• 02

  If you offer any third-party social sign-in, you generally have to offer Sign in with Apple alongside it: another provider to implement, test, and support.

• 03

  Privacy disclosures and a privacy manifest have to be accurate and have to cover your third-party SDKs, which means someone has to audit what those SDKs collect.

• 04

  If you track users across other companies’ apps, the App Tracking Transparency prompt is mandatory, and most people decline it. Treat that as a product decision with revenue consequences.

• 05

  Digital goods and subscriptions consumed inside the app go through In-App Purchase, and Apple takes a commission. Physical goods and services delivered in the real world do not.

Individually these are cheap. Together they are a week or two, and you find out whether your quote included them the first time somebody gets rejected.

SwiftUI is the default way to build iOS interfaces now, and for ordinary product UI it is faster than the UIKit era it replaced: less boilerplate, less layout code, less state plumbing written by hand. It is also younger. For complex text handling, some camera and media work, and a few list and scrolling behaviors, the pragmatic answer is still a UIKit component wrapped for use from SwiftUI. A team that insists on exactly one of the two regardless of the problem will cost you time somewhere, and rarely where you were watching.

The other planning fact is the calendar. Apple ships a major OS release every September and its users adopt it fast, so an app that has not been touched since the spring will be running on an OS it was never tested against by October. Budget a compatibility pass every fall, even in a year when you change nothing about the product. It is usually small. It is rarely zero.

The Apple Developer Program is $99 a year, for as long as the app is on the store. For most projects that is the entire direct platform fee.

$99 / yr

Apple Developer Program, for as long as the app is listed

TestFlight is the part of distribution worth planning around. Internal testers on your own team get builds immediately. External testers, meaning the client, the pilot site, and the twenty people whose opinion decides whether this was worth doing, need a beta review first. That is usually quick and occasionally is not. Building the pilot into the schedule instead of bolting it on at the end is the cheapest quality decision available on this platform.

If the app is for staff rather than the public, check the distribution route before you assume you can skip the store. Apple Business Manager can distribute a private app to a known organization, and the Apple Developer Enterprise Program allows internal distribution with its own annual cost and its own qualification criteria that a lot of companies do not meet. Finding this out in week one is free. Finding it out in week ten is not.

Three situations make a single-platform iOS build defensible on the merits.

A company-owned device fleet

If your field team carries iPhones or iPads that IT issues, configures, and replaces, the second platform buys you nothing at all. This is the cleanest case, and it is common in healthcare, professional services, and anywhere the hardware was standardized years ago.

A consumer product where paid conversion decides everything

In the United States, iOS users spend more per head inside apps than Android users do. A smaller first audience that pays is a better market to test a paid product against than a larger one that does not, and you can add the second platform once the pricing works.

A hardware accessory that shipped Apple-first

Plenty of consumer peripherals publish an iOS SDK first and an Android one eventually. If the device you have to talk to made that choice, it has made your platform choice for you, and arguing with it costs more than accepting it.

It is the wrong call when your audience is international, when the app serves the general public in a market where Android holds the majority, or when it will run on rugged field hardware. That last world is almost entirely Android, and there is no iOS equivalent to buy.