iOS app development

We build iOS apps and we run our own on the App Store, which means we deal with review rejections, annual platform releases and subscription plumbing on our own account, not only on a client's.

iOS work is not just writing the app. It is App Review, entitlements, privacy declarations, subscription handling, and an annual operating system release that will break something. The build is the part everyone quotes for. The rest is the part that delays launches.

What we build

Consumer apps, mostly. Products where somebody opens the app repeatedly and the experience has to justify keeping it installed. Our own portfolio is the clearest statement of what we are good at: an AI assistant, a yoga app, and a children's bedtime story app, together carrying over ten million downloads.

That shapes how we approach client work. We are less interested in whether a feature can be built than in whether anyone will still be using it in week three, because that is the question our own apps live or die on.

What building for iOS actually involves

The app itself

Interface, navigation, data, and the parts nobody demos: what happens with no network, with an expired session, with a device almost out of storage, and when someone backgrounds the app halfway through something important. These states are most of the difference between an app that works and one that merely runs.

Platform integration

• Push notifications, which need a server, certificates, and a genuine reason to interrupt somebody.
• In-app purchases and subscriptions, including restoring purchases, family sharing, and the awkward states around cancellation and refunds.
• Permissions for camera, photos, location, health data and notifications, each of which needs a plain explanation at the moment it is requested.
• Sign in with Apple, which Apple requires if you offer other third-party sign-in options.
• Widgets, share extensions and shortcuts where they earn their place, which is less often than people expect.

App Review and the store listing

Review usually takes a day or two, but preparation takes longer than review. Privacy nutrition labels have to match what the app actually collects. Subscriptions need their terms visible before purchase. Anything using an account needs a working test login and, if you offer accounts, a way to delete them from inside the app. Screenshots and the description are marketing work, not an export step.

The year after launch

Apple ships a major release every autumn. Layouts shift, permissions tighten, deprecated interfaces stop working, and store requirements change with little notice. An iOS app is not a thing you finish. Budget for continuing work whether or not you add a single feature, and treat anyone who does not raise this with suspicion.

How we work

1. Discovery. What the app does, and more usefully what it deliberately does not do. One to three weeks.
2. Design. Flows before screens. Reversing a decision here costs a conversation rather than a sprint.
3. Build, with an installable build on your phone every week from the start. Not screenshots, not a demo driven by someone who knows which parts to avoid.
4. Testing on real devices, running alongside the build rather than bolted on at the end.
5. Submission, launch, and iteration on what real usage shows rather than what we assumed.

You own the source code, the design files and the App Store listing from the first day, not on final payment. The app is built under your Apple Developer account. There is no arrangement where you need us in order to keep running your own product.

When we will tell you not to build an iOS app

If nobody would open your product more than about once a week, they will not keep it installed, and an app puts a download and two store reviews between you and your users in exchange for very little. If your product needs no camera, no notifications, no offline behaviour and no background work, a web product will reach more people for less money.

We would rather say that on a first call than discover it together three months in. It costs us a project and saves you considerably more.

Getting a real number

We scope before we quote. That means asking about screens, what has to be stored, whether it must appear on a second device, which other companies' systems you need to talk to, and what happens after launch. With those answers we give a fixed range before work starts. Without them any number is a sales device that will be revisited later, at your expense.