Mobile applications
Android and iOS Apps, Planned Past the Store Listing
Getting an app into a store is the visible milestone. Whether it still works after a weak signal, an old handset and the next operating system release is what decides if it was worth building. We plan for those from the first screen.
Before you brief anyone
Mobile Projects Run Into the Same Few Surprises
Each starts as a sensible assumption. Better to meet them on this page than in the week before launch.
- 01“One shared codebase halves the work.”
- It shares most of the screens and logic. Camera, payments, background tasks and notifications still need platform-specific code, and each store still reviews the app on its own terms. Shared code is often the right call, but rarely half the effort.
- 02“Store review is a formality.”
- Reviewers reject builds over privacy disclosures, unexplained permissions, missing test logins and broken links. We prepare for each of these, though the store makes the final decision and nobody can promise approval.
- 03“If it runs on our phones, it runs.”
- Your phones are probably recent and fast. Plenty of customers carry older, cheaper handsets with little free storage, so we test on those too.
- 04“Users will install the update.”
- Many will not, sometimes for months. The server has to keep answering older versions, and the app needs a polite way to ask for an update when an old one can no longer be supported.
A made-up example
Offline Behaviour Is Designed, Not Discovered
A hypothetical case, not a client. It shows the decisions that get missed when nobody asks what happens without a signal.
Say a distributor wants an ordering app for sales reps who visit shops in market basements and on rural routes. On a demo over office wifi everything works. In a basement, the order button spins and the rep writes it on paper instead. Planned properly, the app behaves like this:
- Orders are saved on the phone first and sent when a signal returns, with a visible count of what is still waiting.
- If a price changed while the phone was offline, the app flags the order for the rep to confirm rather than guessing.
- Product photos are cached in sizes the handset can afford to store.
- Nothing is marked as sent until the server has confirmed it.
At release
You Leave With the Keys, Not Just the Listing
An app whose signing key sits on one developer's laptop is an app you do not fully control. Here is what passes to you, and what nobody should be promising.
Handed over
- The source code, in a repository you control
- Signing keys and certificates, stored where you can reach them
- Store listing text and disclosures prepared from your material
- Crash reporting configured under your own account
- Written build and release instructions
- A record of which library versions shipped
Not promised
- Approval by any app store
- A position in store search results
- Developer account fees, which are paid by the account holder
- Support for every handset ever sold
Technology
Native Toolchains, Shared Code, and the Server Behind Both
The platform route is chosen against the device features the app needs and the people who will maintain it, not against the lowest first estimate.
Android
When the app leans heavily on the device.
- Kotlin
- Java
- Android SDK
- Jetpack
iOS
Written to feel native on an iPhone.
- Swift
- SwiftUI
Shared code
When both stores need much the same app.
- Flutter
- React Native
Behind the app
Sign-in, data and the interface it calls.
- Node.js
- REST APIs
- Firebase
- PostgreSQL
Delivery
Specified, Tested on Real Handsets, Then Released
Each step ends with something you can read or install yourself, so progress is never just a message saying things are going well.
- 01
Requirement in Writing
We watch the work being done and write down what the software must handle. You correct that document until it matches reality.
- 02
Estimate With Its Limits
The estimate is drawn from the agreed document and states what it leaves out, so a later change can be priced on its own.
- 03
Small Working Releases
Features arrive in pieces you can use and check, rather than all at once near the deadline.
- 04
Tested on Ordinary Conditions
Each release is tried on modest phones, slow connections and the awkward inputs real users type.
- 05
Handover, Then Upkeep
You receive the code, the accounts and the notes. Ongoing care continues only if you choose it.
Start here
Describe Where the App Will Be Used
Tell us who opens it, on what kind of phone, and where the signal is weakest. Those answers shape the build more than any feature list, and we will follow up with the questions that are still open.