Engineering services
Mobile Applications
We build apps for iPhone and Android and handle the releases afterwards. Store submission is part of the job; store approval is Apple’s and Google’s decision, and anyone who promises you a date for it is guessing.
Part of your product’s journey
Of the eight stages we run, this service covers Build. We also run the others.
What this makes possible
Mobile is unforgiving in a way the web is not. You cannot fix a problem in ten minutes, because every release has to pass the app store’s review first. Your users are on a train with one bar of signal. Half of them will not update for months, so last year’s version is still running and still talking to your system. None of this shows up in a prototype, and all of it decides whether the app is usable.
Our approach in more detail
So the work concentrates on the parts nobody demos. What the app does with no connection at all. What happens to the three things the user did offline when the signal returns and one of them clashes with a change somebody made on the website. Whether a push notification actually arrives, and what it opens when tapped. How a release goes to a small share of users first, so a crash affects hundreds rather than everyone. Whether the store’s reviewer can get past your login screen, because a rejection there is avoidable and costs days.
We build most products with React Native and TypeScript. That gives one set of code for both iPhone and Android, with platform-specific pieces written where the two genuinely differ. It is a trade-off, not a rule. The route from code to a released update is automated early, because shipping an update should be routine rather than a day somebody clears their calendar for.
What you get
- Apps for iPhone and Android
- Keeps working without a signal, then catches up when it returns
- Push notifications, and links that open the right screen in the app
- An automated release process
- Store submission, and release to a small group first
- Crash reports, and a check on how each release is doing
How we get there.
- 01
Platforms and offline behaviour
Before any screen, we settle the things that are expensive to reverse. Which platforms, and how far back in operating system versions you support. What the app must be able to do with no connection. How work done offline gets sent up afterwards. And what happens when two people have changed the same thing. That last one needs a business answer. Whoever saved last wins is a decision with consequences, not a default.
- 02
Core build
Navigation, login, the app’s own store of data on the phone and the link back to your system come first, then features on top. Logging in on a phone carries requirements the web does not. The token that keeps a person signed in has to be stored securely. Fingerprint or face unlock where it makes sense. And a rule for what happens when the app has sat unopened for a week. Those are handled at the start, not the week before submission.
- 03
The route to release
Builds for both stores produced automatically, and the digital signatures each store requires set up properly. Internal distribution too, so your team can install a real build on a real phone from week two. Crash reporting is wired in before the first outside tester sees anything, so a bad build is visible immediately.
- 04
Device testing
Real hardware, including a deliberately old and slow Android phone, on deliberately slowed connections and in aeroplane mode. Push notifications checked on each platform. Links that open the app tested from cold, not only when the app is already running. The store’s own rules checked against the finished build before we submit.
- 05
Submission and a staged release
Store listings, screenshots, privacy declarations and data-safety forms prepared with you, then submission and the review cycle. The first release goes to a small share of users and is watched for crashes, then widened once it holds. Before we press the button, we agree how the previous version goes back if something is wrong.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if a mobile-friendly website would do. If you do not need the camera, offline use, push notifications or work happening in the background, a good responsive site avoids store review. It also avoids asking people to install anything, and it avoids maintaining two platforms. We will say so before quoting.
- Not for you if there is no budget beyond launch. Apple and Google each release a new operating system every year, and an app left untouched for eighteen months breaks or gets pulled. Maintenance is a running cost, not an optional extra.
- Not for you if you must be live by a fixed outside date falling within days of submission. Store review is outside anyone’s control, and a rejection resets the clock.
- Not for you if the idea is untested and the goal is to find out whether anyone wants it. A web version tests that in a fraction of the time and cost.
- Not for you if the app depends on a system behind it that does not exist and nobody has budgeted for. The app is the visible half of the work, and usually the smaller half.
A worked example
Hypothetical scenario
Illustrative: a field data collection app
Say your team inspects sites and records what they find on a phone, often in basements and warehouses with no usable signal. The interesting engineering is not the form. It is that the form has to work with no connection at all, hold photographs running to hundreds of megabytes, and survive the phone shutting the app down mid-inspection. Then it has to upload later without creating duplicates, even if the upload is interrupted twice. That means the copy of the data on the phone is the master copy, not a temporary one. Every record carries an identifier created on the phone, so a repeated upload is recognised as the same record rather than a new one. The queue of pending uploads survives a restart. And there is a rule for what happens when somebody in the office edited the same record in the meantime. It also means a screen showing what is still waiting to upload, because field staff will ask. An app of this shape sits at the wider end of the range: ten to sixteen weeks to a first store release. The syncing work routinely takes as long as every screen put together.
An illustration of our approach, not a delivered client project.
How long until it is in the stores?
Ten to sixteen weeks to a first store release is the planning range. The lower end is a focused app built against a system that already exists, which is closer to eight to twelve weeks. The upper end is an app with serious offline and syncing requirements. Where the system behind the app is being built alongside it, plan on three to five months. Add one to two weeks for store review on a first submission, longer if anything is queried. What drives the number is the offline and syncing requirement, how many outside services are involved, and whether payments run through the app, since the stores’ own purchase rules add real work.
Whose developer accounts are used?
Yours, always. The Apple Developer and Google Play accounts are registered to your company, and we work inside them with the access you grant. Publishing under an agency’s account is common, and it is a trap: you cannot move the listing, the reviews or your installed users without that agency’s permission. The signing keys stay in your possession too.
What if we want to move to another team later?
Thirty days’ notice, and the handover is a process rather than a zip file. It covers access to the code and the automated release setup, plus the signing keys. It also covers a written step-by-step for putting out a release, notes on how the app is put together, and a live session with whoever is taking over. Because everything already sits in your accounts, most of it is documentation and a conversation.
Do you build native or cross-platform?
React Native for most products, with platform-specific pieces added where a particular phone capability needs them. We recommend building separately for each platform when the product depends on sustained high-frame-rate graphics, deep access to the hardware, or heavy processing on the phone itself. We will tell you which category you are in during the first conversation, not after you have signed.
Who handles updates after launch?
We can, under a maintenance arrangement, or your team can. Either way the route to a release is automated and documented, so shipping an update does not depend on knowledge living in one person’s head. If we run it, the ongoing work is mostly supporting new operating system versions, keeping the app’s building blocks current, and working through crash reports within an agreed response time.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.