What an iOS app really costs, and how to scope one properly

There are deliberately no price lists here. Any figure without your requirements behind it would be a guess dressed up as data. What follows are the factors any developer should be weighing when they quote, so you can judge a quote and shape a budget.

The biggest cost driver is the number of distinct things the app does

Effort grows with the number of distinct features, screens and states, not with how polished the idea sounds. A useful exercise is to list every screen and, for each one, every state it can be in: empty, loading, full, error, offline, signed out. A “simple” profile screen with editing, validation, photo upload and error handling is several pieces of work, not one.

The features that most often expand a budget:

• Accounts and sign-in. Registration, password reset, Sign in with Apple, account deletion (required by Apple when you offer accounts), and the server side to support them.
• Payments. In-App Purchase or subscriptions for digital content, or a payment provider for physical goods and services, plus receipts, refunds and edge cases.
• Real-time and sync. Chat, live updates, collaboration, or data that syncs between devices and works offline. Offline sync in particular is easy to underestimate.
• Integrations. Each third-party system, such as a CRM, booking engine, stock system or payment provider, brings its own documentation, test accounts and failure modes.
• Content management. If someone needs to change products, articles or prices without a new app release, you need an admin tool or a CMS.
• Notifications. Push notifications need a server that knows when and to whom to send them.
• Hardware and sensors. Bluetooth accessories, HealthKit, camera processing, location in the background. Each adds testing time on real devices.

The backend is often half the project

Many app ideas are really a service with an app on the front. If the app needs accounts, shared data, payments or notifications, something has to run on a server. Options range from managed services that handle authentication and data for you, to a custom API. The choice affects:

• build effort now;
• monthly running costs, which grow with usage;
• how locked in you are to a provider;
• who maintains it, and what happens if they stop.

Ask any developer who quotes for “the app” whether the backend is included, who will host it and who pays for it.

Design: templates, Apple’s system style or a custom brand

An app that uses Apple’s standard components and the system look, carefully, can look excellent and costs less to build and maintain, because it inherits accessibility, Dynamic Type and dark mode support from the system. A heavily custom design with bespoke controls and animation costs more to design, more to build and more to keep working with each iOS release.

Neither is wrong. A consumer brand competing on feel may need custom work; a field-service tool for staff probably doesn’t.

Platforms and devices

• iPhone only, or iPad too? Supporting iPad well means layouts that use the larger screen, not a stretched phone app.
• Apple Watch? A companion app adds a second interface with its own constraints. The Apple Watch articles on this site show what that involves.
• Android as well? This is the biggest single platform decision. Native iOS or cross-platform? covers the trade-offs.
• Oldest iOS version supported. Supporting older versions means more testing and sometimes two code paths. Apple’s minimums also move: since 9 September 2026, apps uploaded to App Store Connect must target iOS 13 or later, according to Apple’s upcoming requirements page, and most new apps reasonably target much more recent versions than that.

Quality work that should be in every estimate

A quote that’s mostly feature lines with little for the rest is optimistic. Typical considerations that belong in an estimate:

• automated tests for business rules and critical journeys (testing guide);
• accessibility: VoiceOver, larger text, contrast (accessibility guide);
• privacy: permission flows, privacy manifest, App Store privacy details and a privacy policy (privacy and review guide);
• beta testing through TestFlight and fixing what testers find;
• App Store assets: screenshots, description, keywords, preview video if wanted;
• project management and communication, which takes real time on both sides.

Costs beyond the build

Some costs are fixed by Apple and easy to check:

• Apple Developer Program: 99 US dollars per membership year, or the local-currency equivalent where available, according to Apple’s membership details. Your app is removed from sale if the membership lapses, so renewal belongs in someone’s diary.
• App Store commission on digital sales: Apple’s standard rate is 30%, or 15% for developers in the App Store Small Business Program and for qualifying subscriptions, per the same membership page. Physical goods and services don’t go through Apple’s payment system.

Others depend on your choices:

• hosting, database and storage for the backend;
• third-party services: maps, email, SMS, analytics, crash reporting, search;
• design assets, fonts or stock imagery licences;
• legal: privacy policy, terms, and in regulated fields, compliance advice;
• marketing, because a published app isn’t the same as a discovered one.

Then there’s the cost of keeping the app working after launch, which deserves its own article: After launch: maintaining an iOS app. A useful planning habit is to budget for upkeep every year rather than treating the launch as the end of spending.

How to scope a project so estimates mean something

A good estimate needs a good brief. The most useful briefs answer:

1. Who is it for, and what problem does it solve for them? One or two sentences.
2. What must someone be able to do in version one? List the journeys, such as “book a class”, “see my bookings”, “cancel with a refund”.
3. What exists already? A website, a database, a booking system, a brand, an API.
4. What does success look like six months after launch? Bookings made, hours saved, subscribers, reviews.
5. What are the constraints? A launch date tied to an event, a budget ceiling, regulatory requirements.

With that, a developer can separate the must-haves from the nice-to-haves and give you options. The iOS app MVP checklist helps you draw the line for version one.

Ways to control cost without cutting quality

• Start smaller than feels comfortable. Launch the core journey, learn from real use, then build what people ask for. The features cut from version one are often never missed.
• Use the platform. Standard components, system sign-in, Apple Pay and existing services save weeks.
• Avoid building an admin tool on day one if a spreadsheet, a simple CMS or a managed backend’s dashboard will do for the first months.
• Pay for discovery. A short, paid scoping phase with wireframes and a technical plan costs far less than building the wrong thing.
• Fix the scope or the date, not both. If the date is fixed, the scope must be allowed to flex, and the other way round.

Questions to ask about any quote

• What exactly is included, and what is excluded? Backend, design, App Store submission, testing, support after launch?
• Is it a fixed price for a fixed scope, or an estimate for time spent? How are changes handled?
• Who owns the code, designs and Apple Developer account at the end? (It should be you; see How to choose an iOS developer.)
• What happens after launch, and what does upkeep look like each year?
• Which assumptions would most change the estimate if they turned out to be wrong?

A developer who answers these clearly is one you can plan with.

Why two quotes for the same idea can differ so much

If you ask several developers to quote from the same short brief, the numbers can be far apart. That usually isn’t greed or naivety. It’s that each one has filled the gaps in the brief with different assumptions:

• one assumes a managed backend, another a custom server;
• one includes design, another expects you to supply it;
• one plans automated tests and accessibility work, another doesn’t mention them;
• one includes App Store submission and a month of support after launch, another stops at “code delivered”.

The fix is to ask each one for their assumptions in writing, then compare like with like. A detailed quote with clear exclusions is more useful than a lower one that’s vague.

Fixed price, time and materials, or phased?

There are three common ways to structure the money, and each shifts risk differently:

• Fixed price for a fixed scope. You know the cost up front, but the scope must be defined in detail, and changes go through a formal change process. Developers price in the risk of the unknown, so it can cost more for the same work.
• Time and materials. You pay for the time spent, usually with an estimate and regular reporting. It’s flexible when requirements will evolve, but you need to watch progress and priorities closely.
• Phased. A small fixed-price discovery phase, then fixed or estimated prices for each milestone once the next stage is understood. This is often the best balance for a new app: commitments grow as uncertainty shrinks.

Whatever the structure, tie payments to things you can see and try, such as a TestFlight build with agreed features working.

Key takeaways

• Cost follows the number of distinct features and states, plus the backend, integrations and design ambition.
• Apple’s own costs are small and published: the annual programme fee and commission on digital sales.
• Testing, accessibility, privacy and App Store preparation belong in every estimate.
• Budget for upkeep every year, not just the build.
• A clear brief and a short discovery phase make estimates far more reliable.

If you have an idea and want an honest view of what it would involve, send me a short description. I’ll reply personally with questions, options and next steps, including whether I’m the right person for it.

Written by Lee Johnson. Published 30 October 2026.