We build iPhone and Android apps and get them through the stores. That includes the parts people forget about: the review rules, the test devices, and what happens when version one meets real users.
Apps get specified in a meeting room and used on a train. Screens that seemed obvious in a workshop turn out to need three taps too many, and the feature everyone argued hardest about goes untouched. Building the whole thing first and finding that out afterwards is the expensive order to do it in. There is also the store to get past, and a rejection over a privacy label can cost you a launch date you have already announced.
We start with a clickable prototype put in front of real users. That round usually reshapes the navigation and cuts a chunk of the planned scope, which is exactly what it is for. Only once the flow holds up do we commit to a platform and a price. During the build we test on real devices as well as simulators: the handsets your analytics say your users carry, plus the Android skins that handle background work and notifications differently. Offline and reconnect behaviour is designed rather than discovered by a driver in a lift.
Store submission has failure modes of its own, so builds and signing are automated and the reviewer notes, demo account and privacy declarations are prepared with the build instead of on the day. Rollouts go out in stages with crash rates watched during the ramp, so a bad build stops itself before the one star reviews arrive. Crash reporting and product analytics ship with version one, which is what turns the first month of live use into a ranked list of fixes rather than a room full of opinions. Then we agree a release rhythm. Small updates every few weeks are easier to review, easier to test and easier to pull back than one large release a year.
Phones lose signal, and they lose it in the places people work: lifts, basements, warehouses, trains, the far end of a site. This is the question that separates an app that survives contact with its users from one that gets uninstalled in the first week, and it has to be answered on purpose. If the app only reads, keeping the last loaded data on screen with an honest note about when it was fetched covers most of the problem cheaply. If the app writes, somebody has to decide what happens when the same record was changed on a phone and on a desk while the two could not see each other. Last write wins is a decision, not a default, and it is the wrong one for anything involving stock or money. We settle this during discovery, because retrofitting it means rewriting the data layer.
Most people meet your app as a title, an icon, three screenshots and a star rating, and decide from that. It is the cheapest surface to get right and the one most often left to the last afternoon. The title carries the words somebody would actually search; the first two screenshots have to make sense with the sound off and no context; the description's opening line is the only part shown before a tap. Ratings compound, so the prompt for them belongs after a moment where the app has just done something useful, not on the second launch. None of this is a substitute for the app being good, but a good app with a careless listing is a good app nobody installs.
Swift and Kotlin where the app leans on the device: camera, background location, Bluetooth hardware, heavy animation. Fewer fights with the platform, and the best answer when the phone itself is the product.
One codebase across both stores where the app is screens over an API. Cheaper to build and, more to the point, cheaper to keep alive for the five years afterwards.
A clickable prototype in real hands before the full build is paid for. It routinely reshapes the navigation and cuts scope, which is the entire reason to do it first.
An app whose developer has gone, or that has not shipped an update in two OS releases. We try to build it from a clean checkout first, then tell you honestly whether to inherit it or replace it.
The service the app talks to, built with it rather than by a separate supplier. What gets cached, what gets retried and what an error looks like to a user in a queue are one conversation, not two.
Staged rollouts, crash reporting from version one, and the yearly OS releases that quietly break a permission or deprecate an API. Apps are started at launch, not finished.
What the app is for, who carries it, and the three questions that decide the cost: what it does offline, what it connects to, and whether it needs the device hardware.
A clickable flow in front of real users before a platform is chosen. This round is meant to change the plan, and it usually does. Committing to a price before it is how apps get built twice.
Native or shared, decided by what the prototype proved rather than by preference. Built in sprints against a running app you can install, not a demo video.
Tested on the handsets your analytics say your users carry, the older ones included, plus the Android skins that treat background work and notifications differently.
Reviewer notes, demo login and privacy declarations prepared with the build. Staged rollout with crash rates watched on the ramp, so a bad build stops before the one star reviews.
The cheapest version of this project is the one where a prototype changes your mind before the build is paid for, rather than after it ships.
The developer has gone, the certificate is missing, or it has not survived the last two OS releases. That is a rescue, and it starts by finding out whether it still builds.
Which is what happens when testing ran on simulators and a current handset. Your customers are carrying phones several years older than your team is.
Warehouses, lifts, basements, vans, sites. If that is your users, offline behaviour is the product decision that everything else hangs off.
It depends on what the app does. If it leans on the camera, background location, Bluetooth hardware or heavy animation, native gives you fewer fights with the platform. If the app is screens over an API and covering both stores quickly matters more than the last ten per cent of platform feel, one shared codebase is the cheaper answer and stays cheaper for years. We will tell you which of those you are before quoting, not after.
The build is only part of it. Apple reviews every submission and can come back with questions, and both stores need accounts, listings, screenshots, a privacy declaration and a support address before they will take anything. We set those up early rather than in the last week, because a finished app waiting on a developer account is the most avoidable delay in this work.
Apps are not finished at launch, they are started. Both platforms ship a major OS release every year, and each one breaks something: a permission that now needs a reason, an API that is deprecated, a screen size nobody had. We plan for the versions that follow the first one, watch the crash reporting and the store reviews, and keep the app buildable so a fix does not begin with a week of dependency archaeology.
Yes, and they should be created in your company name before the build finishes. The App Store and Play Store accounts, the signing certificates and the listing all sit with you. An app published under an agency account is an app you cannot update without that agency, which is a position worth never being in.
The two things that move the number most are how much the app has to do when it is offline, and how many systems it has to talk to. A catalogue that reads from an API and works only online is a contained piece of work. An app that has to keep working in a lift, a warehouse or a basement, then reconcile what changed when the signal comes back, is a different build, because the hard part is not the screens, it is deciding who wins when the same record was edited in two places. We scope against a written feature list so you can see which of those you are paying for.
Often, and the first step is always the same: we try to build it. Not read it, build it. An app whose source compiles from a clean checkout on a new machine is a takeover. One that only ever built on a departed developer's laptop, with unpinned dependencies and a signing certificate nobody can find, is a rescue, and it is worth knowing which you have before committing to a roadmap. We do that assessment as a short fixed piece of work and tell you honestly if rebuilding is cheaper than inheriting.
Both, and it is usually a mistake to split them across two suppliers on a first build. The app and the API have to agree on a great deal: what is cached, what is paginated, what happens on a retry, and what an error looks like to a user standing in a queue. Those conversations are cheaper inside one team. If you already have an API we build against it, and we will tell you early if it will not support the app you are asking for, because that is a conversation that gets more expensive every week it is delayed.
That is a product decision before it is a technical one, and it is worth making deliberately rather than discovering. Fully offline means the app holds its own copy of the data and reconciles later, which is the most useful and the most expensive answer. Read-only offline, where the last loaded data stays visible but nothing can be changed, covers a lot of real cases for much less. Online-only is legitimate too, provided the app says so clearly instead of showing an empty screen that looks broken. We agree which of the three you want during discovery.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
