Mobile App Development

When is a native app the wrong answer?

When the thing you are describing is really a website with a login, or software people will use at a desk. Five patterns come up repeatedly, and in every one of them the store submission, the two codebases and the annual maintenance are cost without corresponding benefit.

• The main use will be at a desk or on a tablet
• It is essentially a website with a login — which is a browser-based application, not a mobile product
• You need it working across every platform on one budget
• You will update it frequently and do not want to wait for store review
• Your users are staff, customers or partners you can simply send a link to, in which case a properly built responsive website may be the whole answer

What do we build?

Eight things, of which only the first three are the app itself: iOS, Android and cross-platform builds. The rest is the server side, the admin tooling, the integrations, the store work and the progressive web app option — consistently the part clients have not budgeted for and always the part they need.

• iOS applications. Native Swift where the requirement justifies it — heavy device integration, demanding performance, platform-specific features.
• Android applications. Native Kotlin, on the same basis.
• Cross-platform applications. React Native, producing iOS and Android from one codebase. For most business applications this is the sensible choice: one build, one set of updates, substantially lower cost, and a user experience that is genuinely good rather than merely acceptable. The trade-off is that some deep platform features need native modules written alongside.
• Backends and APIs. The part clients rarely budget for and always need. An app is a window onto a server — user accounts, data storage, business logic, integrations, push notification infrastructure. This is often more than half the actual work, and it is the same discipline as any bespoke system we build.
• Admin dashboards. Somewhere for your team to manage users, content, orders and support without a developer running database queries. Needed from day one and routinely forgotten until week ten.
• Integrations. Connecting the app to what you already run — your CRM, your stock system, your accounts, your booking platform. Where the CRM itself is the problem rather than the app, a custom system built around your process is usually the better place to start.
• App store submission. Preparation, store listings, screenshots, privacy declarations, review responses, and the resubmissions that follow a rejection. Apple in particular rejects first submissions routinely, and knowing why in advance saves weeks.
• Progressive web apps. For the requirements that do not justify a store presence, an installable browser-based product with offline support and push notifications on most platforms.

Should you build native or cross-platform?

Our default recommendation is cross-platform, because most business applications do not need what native buys and every client benefits from a single codebase to maintain. We will recommend native when the requirement genuinely calls for it, and we will explain why rather than asserting it.

How does an app get from idea to the store?

Eight stages: discovery, design, backend, build, testing, store submission, launch and ongoing work. The backend usually starts before the app does, because the app needs something to talk to, and store submission needs a slot of its own that most plans forget to allow for.

• Discovery and scoping. Who uses it, what job it does, which platforms, what it connects to, and what the first release deliberately leaves out. Output: a written scope and a fixed price for phase one.
• Design and prototype. Screens designed and made clickable, tested on an actual phone before development starts. Interfaces that work on a desktop mock-up and fail in a hand are a common and avoidable expense.
• Backend and API. Usually starts before the app itself, because the app needs something to talk to.
• Build in two-week sprints. Installable test builds through TestFlight and Play Console internal testing at the end of each, so you use it on your own phone throughout rather than watching a screen recording.
• Testing. Real devices, not just simulators. Multiple OS versions, various screen sizes, poor network conditions, and the awkward cases — interrupted payments, expired sessions, permission denials.
• Store submission. Listings, screenshots, privacy declarations, and handling review feedback. Budget one to two weeks for this, and occasionally more with Apple.
• Launch and monitoring. Crash reporting, analytics and performance monitoring live from day one, so you find out about problems from data rather than from reviews.
• Ongoing. OS updates twice a year, store policy changes, bug fixes and new features. Planned for, not treated as a surprise.

What does app store review involve, and what usually causes a rejection?

Every release goes to Apple or Google for review before users can install it, and Apple in particular often rejects a first submission over something procedural. The usual causes are missing review access, privacy declarations that do not match the app, unfinished content and crashes. All of them are preventable before submission.

What are the running costs of an app?

Five, and none of them is optional: the two developer programmes, backend hosting, messaging services and maintenance. This is the section most agencies leave out of the proposal, which is how a business ends up with an app it can afford to build and cannot afford to keep.

• Apple Developer Program membership, charged annually
• Google Play Developer registration, charged once
• Backend hosting, charged on usage and growing as the app grows — the same infrastructure question that applies to a hosted product platform
• Push notification and messaging services, charged on usage
• Maintenance, budgeted at 15 to 20 per cent of the build cost per year for OS updates, store policy changes and bug fixes. This is an industry norm, not a markup, and an app that does not receive it will eventually stop working.

Who owns the source code and the store accounts?

You do, and the store accounts matter more than they sound. Source code, designs and the backend are yours on final payment, with the repository handed over. The Apple and Google accounts should be registered to your company from the start, because moving a published app between developer accounts is genuinely painful.

• The Apple Developer and Google Play accounts should be registered to your company, not ours, with you as account holder. An app published under an agency's developer account is extremely awkward to move, and it is a genuine hostage situation that catches businesses out every year. If we set them up for you, they are in your name from the start.
• Backend infrastructure sits in your accounts, so you are never locked out of your own data.
• No lock-in. Standard technologies and documented code, so any competent developer can pick it up.
• We do not reuse code written for your app in another client's project.

What happens if you want to move to another developer?

You leave with everything needed to ship the next release without us: the repository and its history, the backend and its data, the credentials, the documentation, and the store accounts with the signing keys that belong to them. Without those keys, the next developer cannot update the app your customers already have.

• The repository with its full commit history, covering the app and the backend, rather than a snapshot of the current files — the same handover terms as a bespoke system built for the business behind it.
• The database schema and a full data export — accounts, content, transactions — so the backend can be stood up elsewhere with real records in it.
• Environment variables and third-party credentials: API keys, mail and SMS providers, analytics, crash reporting and file storage, listed with what each one is for.
• The API documentation the app depends on — endpoints, authentication, versioning and webhook payloads — because an app talking to an undocumented backend is two problems rather than one.
• Deployment and build instructions for both halves: how to produce a signed release for each store, and how a backend release reaches production.
• App Store Connect and Google Play accounts in your own company name. These should be in your name from day one rather than ours — an app published under an agency's developer account is awkward to move, in the same way a hosting account left in a supplier's name is.
• The signing keys, certificates and provisioning profiles, with the passwords that unlock them. The Android upload key in particular cannot be replaced casually, and losing it means the next update never reaches existing users.
• Push notification credentials — the APNs key and the Firebase project — so notifications keep working through the handover rather than going quiet the week the accounts change.
• The domain, DNS, backend hosting and monitoring accounts, already registered to you, so moving to a new agency or an in-house team is an administrative transfer rather than a negotiation.