iOS apps for businesses, from idea to the App Store

Native iOS apps built around your users, from discovery to TestFlight and the App Store, or an existing web service that becomes an iPhone app.

A native iOS app is installed from the App Store and really uses the phone: notifications, camera, location, offline mode and Face ID. That covers both new apps and web services that already work and now need to live on the phone.

Who it is for

There are two common starting points:

• A new app. You have an idea or a workflow that needs what only a native app can give: notifications, the camera or offline mode.
• An existing web service. Customers book a time, sign in or follow a case in a web service that already works and is mobile-friendly, and now it should also exist as an iPhone app.

If the workflow is not yet proven, a web app is often a better first step, since it opens in the browser and works on every device. A common approach is to start with the web app, let it prove that the workflow works, and build the native app once there are users who need it. Why a native app costs more is in What does it cost to build an app?, and how to scope a first version in What is an MVP, and what should the first version contain?.

What is included

A new app is built as a product build:

• Discovery and architecture. What the app should do, and what can wait for the next version.
• Build, test and deploy. With analytics and admin from day one, so someone on your side can correct, add and remove without calling a developer.
• TestFlight and App Store submission. You try a test version before the app is submitted.
• Post-launch fixes. 30 days of fixes after launch are included.

An existing web service that is to become an iPhone app gets its own, smaller scope:

• A review of the existing web service.
• The changes it needs for the iPhone.
• A test version via TestFlight.
• Help with the first App Store submission.

Larger changes to the backend, sign-in or payments, and new features, are quoted separately. Your Apple Developer account and ongoing operation are not included. Apple reviews every app, and approval cannot be guaranteed.

How it works

First a free call, then the scope and a fixed price in writing before anything is built. For an existing web service, the final fixed price is given after a review of the service. You try the app in TestFlight before it is submitted, and everything runs on your own accounts. The whole way of working is on the home page.

Before the price it helps to know what a user should be able to do in the app, in one sentence, which are the three most common cases and the two most awkward ones, whether anything is to be paid for in the app, and who on your side owns the product and can answer questions while it is built.

An app keeps costing something after launch. An Apple developer account has an annual fee, every update is reviewed before it reaches users, and iOS gets new versions every year. An app that is never touched slowly breaks.

Price

Common questions

Can my web service become an iPhone app?

Often, yes, if customers use it to book, sign in or follow a case, for example. I go through what already exists and what needs adapting for the iPhone. The app has to meet Apple's requirements, and approval in the App Store cannot be guaranteed.

What drives the price of an app?

How much the app should do for the user, not how many screens it has: accounts and roles, data, flows with exceptions, integrations and admin. That is why two quotes for the same app can differ a great deal without either of them being wrong.

Why not both iOS and Android from the start?

Each platform is a build and a release of its own, even when they show the same thing. Start where your users are, or with a web app that works on every device.

Who owns the app?

You do. The code is delivered into your repository with documentation, and the App Store account, the database and the domain should be in your name. What a handover should contain is in Who owns the code?.