iOS and Android app development

When an app belongs in the store, and when it does not

We will start with the question that saves the most money, because most studios skip it: does this need to be a native app at all?

A native app earns its cost when it needs the phone rather than the browser — reliable push notifications, background location, the camera or Bluetooth at close range, offline work that survives a dead signal, biometric sign-in, or an intense interface where every frame matters. It also earns it when the store itself is the distribution channel: if people look for you by searching the App Store, being absent from it is the whole problem.

A native app is the wrong answer when the real requirement is "our customers should be able to do this on their phone". That is a website's job, and a well-built site or a web app does it for a fraction of the cost, with no install to persuade anyone into and no review queue between a bug and its fix. We say this to people who arrive asking for an app, regularly, and it costs us work.

Two stores, two sets of rules

Shipping to iOS and Android is not one job done twice. Apple reviews every build against guidelines that change, and it enforces conventions about sign-in, payments and privacy disclosure. Google's review is generally faster but its policy enforcement is no softer, and Android's device and OS spread is genuinely wide — the phone in someone's hand may be four years old and running a version you have never tested on unless you plan for it.

Both stores require a developer account in the business's own name, an accurate privacy declaration, and a listing built rather than filled in. We set all of it up in your accounts, not ours, so the app is never hostage to a vendor relationship.

One codebase or two

Most business apps do not need two separate native codebases. A single cross-platform codebase that compiles to real native apps on both stores gives you one team, one set of fixes and one release rhythm — and for the overwhelming majority of apps the user cannot tell. Two fully separate codebases are the right call when the app leans hard on platform-specific capabilities or when the interface has to feel indistinguishable from the operating system's own.

We will tell you which your app is at the consultation, with the reason, rather than defaulting to whichever is more billable.

The costs that arrive after launch

The build is the visible cost. The recurring one is that an app is never finished: iOS and Android each ship a major version every year, and an app that is not updated eventually stops working, gets flagged as outdated, and can be removed from the store. Budget for maintenance from the start — our care plan starts at $99/mo and scales with the app — or plan honestly for the app to have a shelf life.

What we have shipped

Keleinik is our own product and the clearest example of the range: a private attendant for Orthodox priests that runs in Telegram, with a web cabinet at keleinik.com and an app in the App Store. One product, three surfaces, one team — which is exactly the argument for not splitting an app across three vendors.

How the release actually works

The part clients least expect is that you do not control the calendar at the end. Store review is a queue: usually days, occasionally longer, and a rejection costs another round trip. So a launch date is planned backwards from review, with slack in it, and we do not promise a date we cannot hold.

Internal testing first. Before anything reaches the public, the build goes to TestFlight on iOS and an internal track on Google Play. Real people on real devices find the things a simulator never will — the phone that is three years old, the one with the enormous system font, the one that runs out of storage mid-download.

Then a phased release. Both stores can ship to a slice of your users first. We use it. If a crash rate spikes, it spikes for a small percentage and the rollout halts, rather than reaching everyone at once on a Friday afternoon.

Then monitoring, and the next build. Crash reporting and adoption go in from the first release, because "it works on my phone" is not a measurement. What comes back shapes the following version.

Accessibility is not optional on a phone

Dynamic type, VoiceOver and TalkBack, tap targets big enough for a real thumb, and contrast that survives sunlight. This costs almost nothing when designed in and is expensive to retrofit — and on iOS, accessibility problems are among the things review will actually send back.

Privacy declarations have teeth

Both stores require you to declare what data the app collects and what it does with it, and both will pull an app whose declaration does not match its behaviour. We keep the declaration accurate by keeping the data collection minimal — the easiest privacy label to defend is the one where the app barely collects anything.

Being found: the store is a search engine too

App Store Optimisation is its own discipline: the app name and subtitle carry ranking weight, the keyword field on iOS is finite and worth arguing about, and the screenshots decide the install more than the description ever will. It works alongside — not instead of — the web search work that gets people to the page where they hear about the app in the first place.

What you own at the end

The source, the documentation, the signing keys, and the developer accounts. If you take the project to another team, nothing about how we build it is designed to make that difficult. That is a deliberate choice: a studio that keeps clients through lock-in has stopped competing on the work.